Transcript SDA-Lecture-19.pptx

SOFTWARE DESIGN AND
ARCHITECTURE
LECTURE 19
Review
• Basic Concepts of Object Oriented
• Modeling
• UML and OO Modeling
Out line
• Software Requirements
• Requirements Engineering Process
What is a requirement?
• It is about WHAT not HOW
• Requirements are the descriptions of the
services provided by a system and its
operational constraints
• It may range from a high level abstract
statement to a detailed mathematical
specification
What is requirements engineering?
• It is the process of discovering, analyzing,
documenting and validating the requirements
of the system
• Each software development process goes
through the phase of requirements
engineering
Why requirements?
• What are the advantages of a complete set of
documented requirements?
– Ensures the user (not the developer) drives system
functionalities
– Helps avoiding confusion and arguments
– Helps minimizing the changes
• Changes in requirements are expensive. Changing
the requirements costs:
– 3 x as much during the design phase
– 5-10 x as much during implementation
– 10-100 x as much after release [Code Complete, p30]
Why requirements?
• 2/3 of finished system errors are requirements and
design errors [RG]
• A careful requirements process doesn’t mean there
will be no changes later
– Average project experiences about 25% changes in the
requirements
– This accounts for 70-80% if the rework of the project [Code
Complete, p40]
– Important to plan for requirements changes
• The case of critical applications
Different levels of abstraction
• User requirements (abstract +)
– Usually the first attempt for the description of the
requirements
– Services and constraints of the system
– In natural language or diagrams
– Readable by everybody
– Serve business objectives
• System requirements (abstract -)
–
–
–
–
Services and constraints of the system in detail
Useful for the design and development
Precise and cover all cases
Structured presentation
Example
• User requirement: The library system should provide a
way to allow a patron to borrow a book from the
library.
• System requirement: The library system should provide
a withdraw interaction that allows a patron to
withdraw a book given the isbn and copy number of
the book to be withdrawn. The interaction fails if: the
book is already withdrawn, the book is not in the
library's collection, the patron has already withdrawn 5
books, the patron owes more than $5, the book is on
hold by someone else. Otherwise…(To be completed)
Types of requirements
• Functional requirements
– Services the system should provide
– What the system should do or not in reaction to particular situations
• Non-functional requirements
– Constraints on the services or functions offered by the system
– Examples: Timing constraints, constraints on the development
process (CASE, language, development method…), standards etc
• Domain requirements
– From the application domain of the system
– May be functional or non-functional
– Examples: Medicine, library, physics, chemistry
User requirements
• First attempt to describe functional and non-functional
requirements
– Understandable by the user
• Problems:
– Lack of clarity - ambiguous language
– Requirements confusion - functional, non-functional
requirements, design information are not distinguished
– Requirements amalgamation – several requirements are
defined as a single one
– Incompleteness – requirements may be missing
– Inconsistency – requirements may contradict themselves
User requirements
• Guideline to minimize the issues:
–
–
–
–
Separate requirements
Include a rationale for each requirement
Invent or use a standard form/template
Distinguish requirements priorities
• Example: MoSCoW (Must, Shall, Could, Want/Will (no TBD))
– Avoid technical jargon
– Testable (write test cases)
– Deliverables
System requirements
• Elaborate the user requirements to get a precise,
detailed and complete version of them
• Used by designers and developers
• An important aspect is how to present/write system
requirements
– Natural language is often used!
• The difference between user and system
requirements must not be thought as a detail
System requirements
• Example: If sales for current month are below target
sales, then report is to be printed unless difference
between target sales and actual sales is less than half
of difference between target sales and actual sales in
previous month, or if difference between target sales
and actual sales for the current month is less than
5%.
• Problems:
– Difficult to read
– Ambiguity: sales and actual sales, 5% of what?
– Incomplete: what if sales are above target sales?
Writing system requirements
• Natural language (informal requirements)
– Reviled by academics
– But widely practiced: everybody can read them, finding a better
notation is hard
• Structured natural language
– Forms/templates are used to bring some rigor to natural language
presentations
• Graphical notations
– Using boxes, arrows… but they mean different things to different
people
• Formal specification
– Based on logic, state machines…
– Hard to understand for many people
Non-functional requirements
• They can be further categorized into:
– Product requirements
• Product behavior
• Ex: Timing, performance, memory, reliability, portability, usability
– Organizational requirements
• Policies and procedures in the customer’s and developer’s organizations
• Example: Process requirements, implementation requirements, delivery
requirements
– External requirements
•
• Factors externals to the system and the development process
• Example: Interoperability, legislation, ethics
Non-functional requirements may be more critical than functional requirements.
(The system may be useless…)
Non-functional requirements
Non-functional
requir ements
Product
requir ements
Ef ficiency
requir ements
Reliability
requir ements
Usability
requirements
Performance
requirements
Or ganizational
requir ements
Portability
requirements
Delivery
requirements
Space
requir ements
External
requirements
Interoperability
requirements
Implementation
requir ements
Ethical
requirements
Standards
requirements
Legislative
requirements
Privacy
requirements
Safety
requirements
Non-functional requirements
• It is important to be able to test/verify/check
non-functional requirements
Property
Sp eed
Size
Ease of use
Reliability
Rob ustn es s
Po rtability
Meas ure
Pro cess ed trans action s/s econd
User/Event resp ons e time
Screen refres h time
K Bytes
Number of RAM chips
Trainin g time
Number of h elp frames
Mean time to failure
Pro bab ility of u nav ailability
Rate o f failure occurrence
Availab ility
Time to restart after failu re
Percentage of even ts cau sin g failure
Pro bab ility of d ata co rruptio n on failure
Percentage of target dep end ent statemen ts
Number of target sy stems
Requirement engineering
• 5 important activities:
– Feasibility study
– Requirements elicitation and analysis
– Requirements documentation
– Requirements validation
– Requirements management
Requirement engineering
Feasibility
study
Requirements
elicitation and
analysis
Requir ements
specification
Feasibility
report
Requirements
validation
System
models
User and system
requirements
Requirements
document
Feasibility study
• It is done at first to decide whether or not the
project is worthwhile
• Look at different perspectives:
– Market analysis, financial, schedule, technical,
resource, legal…
• Should make you aware of the risks
Feasibility study
• Doing the study
– Consult information sources: managers, software
engineers, end users…
– Based on information collection (interviews,
surveys, questionnaires…)
• Should be short (2-3 weeks)
Feasibility study
•
•
•
•
•
•
•
What if the system wasn’t implemented?
What are current process problems?
Do technical resources exist?
What is the risk associated with the technology?
Is new technology needed? What skills?
How will the proposed project help?
How does the proposed project contribute to the
overall objectives of the organization?
• Have the benefits identified with the system being
identified clearly?
Feasibility study
•
•
•
•
•
•
What will be the integration problems?
What facilities must be supported by the system?
What is the risk associated with cost and schedule?
What are the potential disadvantages/advantages?
Are there legal issues?
Are there issues linked with the fact that this is an
offshore project?
• …
Review
• Software Requirements
• Requirements Engineering Process
References
• Software Engineering. Ian Sommerville. 6th edition. Pearson.
• Code Complete. Steve McConnell. (CC)
• The art of requirements triage. Alan M. Davis. Computer. IEEE.
March 2003.
• Testing whether requirements are right. Robin F. Goldsmith,
JD. Go Pro Management Inc. NYC Spin Meeting. December
2004. (RG)
• Software Requirements. Karl E. Wieger. Windows Press.
• Dr. Gotel’s research web page
• Dr. Barrett’s slides, NYU