Software Requirements and the Requirements Engineering Process - - PowerPoint PPT Presentation
Software Requirements and the Requirements Engineering Process Chapters 5 and 6 References Software Engineering. Ian Sommerville. 6th edition. Pearson. Code Complete. Steve McConnell. (CC) The art of requirements triage. Alan M.
Software Engineering. Ian Sommerville. 6th
Code Complete. Steve McConnell. (CC) The art of requirements triage. Alan M. Davis.
Testing whether requirements are right. Robin
Software Requirements. Karl E. Wieger.
Dr. Gotel’s research web page Dr. Barrett’s slides, NYU
It is about WHAT not HOW Nothing can be said obvious Requirements are the descriptions of the services
It may range from a high level abstract statement to
It may be as complex as a 500 pages of description It may serve as the basis for a bid for a contract or
It is the process of discovering, analyzing,
Each software development process goes
What are the advantages of a complete
Ensures the user (not the developer) drives
Helps avoiding confusion and arguments Helps minimizing the changes
Changes in requirements are expensive.
3 x as much during the design phase 5-10 x as much during implementation 10-100 x as much after release [Code
2/3 of finished system errors are
A careful requirements process doesn’t
Average project experiences about 25%
This accounts for 70-80% if the rework of
Important to plan for requirements changes
The case of critical applications
User requirements (abstract)
Usually the first attempt for the description of
Services and constraints of the system In natural language or diagrams Readable by everybody Serve business objectives
System requirements (NOT abstract)
Services and constraints of the system in detail Useful for the design and development Precise and cover all cases Structured presentation
User requirement: As a user who found a new job
System requirement: A registered user on the academic
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 (e.g., one semester), 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
Note: You can have all of user/system functional/non- functional requirements.
First attempt to describe functional and non-
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
Guideline to minimize the issues:
Separate requirements – separate the requirements,
Include a rationale for each requirement – helps clarify
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
Elaborate the user requirements to get
Used by designers and developers An important aspect is how to
Natural language is often used!
The difference between user and
Example: If sales for current month are below
Problems:
Difficult to read Ambiguity: sales and actual sales, 5% of what? Incomplete: what if sales are above target sales?
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
Archimedes (ca. 250 bc)
Any sphere is equal to 4 times the cone which has
Today
V = 4/3 pi r 3
How is this bit of history relevant for software
Formal is better only if everybody understands it It may take a long time to find a good notation Software requirements is an area of research
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…)
Perfor mance requirements Spac e requirements U sa bility requirements E fficiency r equirements Relia bility requirements P
tability requirem ents Inter
requirements E thical requirements L egislative requirements Implementation requirements Standa rds requirements D elivery requirements Safety requirements Privacy requirements Pr
t requirements O rga nizational requirements E xternal requirements N
requirements
It is important to be able to test/verify/check non-
Property Measure Speed Processed transactions/second User/Event response time Screen refresh time Size K Bytes Number of RAM chips Ease of use Training time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems
Your project descriptions (Available on
Very readable Some ambiguities
Examples of templates:
Microsoft template. Karl E. Wiegers.
Volere template
http://www.volere.co.uk
5 important activities:
Feasibility study
Requirements elicitation and analysis
Requirements documentation
Requirements validation
Requirements management
F easib ility stud y Requirem ents elicitation and analysis R equirem ents specification Requirem ents va lidation F easib ility rep
System m
U ser and sy stem req uirem ents Req uirem ents do cu m ent
It is done at first to decide whether or not the
Look at different perspectives:
Market analysis, financial, schedule, technical, resource, legal…
Should make you aware of the risks
Doing the study
Consult information sources: managers, software engineers, end users…
Based on information collection (interviews, surveys, questionnaires…)
Should be short (2-3 weeks)
What if the system wasn’t implemented? What are current process problems? Do technical resources exist? What is the risk associated with the
Is new technology needed? What skills? How will the proposed project help? How does the proposed project contribute to
Have the benefits identified with the system
What will be the integration problems? What facilities must be supported by the
What is the risk associated with cost
What are the potential
Are there legal issues? Are there issues linked with the fact that
…