Scribd
Upload
44 views3 pages

Logic Chapter 2 - Lecture

The document discusses requirements for software projects and how decision models can improve requirements. It defines what requirements are and lists their characteristics. Requirements can be expressed through textual statements, use cases, prototypes, and models. Textual statements are primarily used for contractual purposes while use cases describe actor interactions. Prototypes help visualize interfaces and screen flow. Different models represent various aspects of the system, like business processes. Overall, decision models can dramatically improve requirements quality and allow systems to be developed at lower cost and faster timelines.

Uploaded by

Karen Cael
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
44 views3 pages

Logic Chapter 2 - Lecture

The document discusses requirements for software projects and how decision models can improve requirements. It defines what requirements are and lists their characteristics. Requirements can be expressed through textual statements, use cases, prototypes, and models. Textual statements are primarily used for contractual purposes while use cases describe actor interactions. Prototypes help visualize interfaces and screen flow. Different models represent various aspects of the system, like business processes. Overall, decision models can dramatically improve requirements quality and allow systems to be developed at lower cost and faster timelines.

Uploaded by

Karen Cael
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

BUSINESS LOGIC

Chapter 4
”how the decision model improves requirements, business analysis and testing”
- “the system shall…” for mandatory
 WHAT ARE REQUIREMENTS? requirements
- condition or capability needed by a user to - “the system should…” for preferred
solve a problem or achieve an objective requirements
- condition or capability that is needed to be - high risk of misunderstanding because of
met by a system to satisfy a contract, language
standard, specification or other formally - usually written after other types of
imposed document requirements as it is used to explain the nature
- better requirements are needed because of
the high rate of system failures  Characteristics of a well-formulated
textual requirement
 Requirements for software project 1. Cohesive - only addresses 1 thing
purposes 2. Complete - no missing info
Functional Nonfunctional 3. Consistent - does not contradict
Requirements Requirements another requirement
- for functions the system - for constraints of the 4. Correct - meets the business needs
performs system 5. Current - is not obsolete
- deliver business value - includes constraints on 6. Feasible - can be implemented within
system performance, the constraints
reliability, and and other 7. Unambiguous - clear and concise
overall characteristic 8. Mandatory - absence of requirement
- includes processes, will result to deficiency
calculations, data 9. Externally Observable
manipulation and 10. Relevant - related to business
reporting rationale
11. Verifiable

 Effects of Decision Models to Systems II. Business use cases - describe interactions
- DM dramatically improves the quality of between actors and the system for a specific
requirements for projects that develop purpose
software systems
- DM creates systems at lower cost and
shorter time cycles

 WAYS OF EXPRESSING
REQUIREMENTS
I. Textual Statements
- used as the principal way of expressing
requirements
- primarily for contractual purposes

CAEL, MICHELLE KAREN JOY BSA 2A


- provides basic course of action when all - In Rapid Application Development, the
goes well, and alternative actions when prototype becomes a working prototype, then
something goes wrong eventually becomes a software
- help stakeholders better understand
requirements within the context of actor IV. Models - “a description or analogy used to
interaction help visualize something that cannot be
directly observed”
- represents reality for a purpose
- represents different aspects of reality so that
each may be addressed individually
- used to build a complete view of the
proposed system

 Aspects that may be modeled


1. Motivation - the “why”; may reflect
organization’s internal and external objectives
2. Organization - people and roles that interact
in a system
3. Location - physical locales of system
hardware and software

Example:  Why Different Models and How Do They


Connect?
1. Each model reduces complexity
2. Each model enables independent change of
its aspect from other aspects
3. Each aspect is best represented by a
specifically tailored model

Connection Points allow viewers to


understand the relation of each model to the
other

 Different Models in Requirements


1. Business Planning Models - strategic and
operational plans
2. Business Process Models - depict required
III. Prototypes - help describe the user flow of activity
interfaces needed in the system 3. Semantic Models - contain glossary, fact
- mock-up of software solution used to types and logical data structures
visualize 4. Organization and location models - contain
- interface is displayed either on a screen or a the relevant physical location of the system
flat diagram (wireframes) and stakeholders
- provides the users with a more tangible idea
of the software
- most valuable use is for user to understand
screen flow and layout

CAEL, MICHELLE KAREN JOY BSA 2A


V. Code - design of the system and derives
requirements from artifacts after the code is
complete
- From the proponents of Agile Development
Approach
- software development approach based
on iterative development
- Agilists do not live with the idea of a
requirement that is collected in advance
of development
- In Agile approach, requirements fully
emerge during the iterative process

 BUSINESS LOGIC IN CLASSICAL


FUNCTIONAL REQUIREMENTS
 Requirements Change but Business Logic
Changes More Often, and Rapidly

CAEL, MICHELLE KAREN JOY BSA 2A

You might also like