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
