1. SOFTWARE DESIGN AND ARCHITECTURE
LECTURE 19

2. Review
Basic Concepts of Object Oriented
Modeling
UML and OO Modeling

3. Out line
Software Requirements
Requirements Engineering Process

4. 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

5. 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

6. 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
x as much after release [Code Complete, p30]

7. 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

8. 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

9. 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)

10. 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

11. 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

12. 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

13. 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

14. 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?

15. 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

16. 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…)

17. Non-functional requirements

18. Non-functional requirements
It is important to be able to test/verify/check non-functional requirements

19. Requirement engineering
5 important activities:
Feasibility study
Requirements elicitation and analysis
Requirements documentation
Requirements validation
Requirements management

20. Requirement engineering

21. 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

22. Feasibility study Doing the study Should be short (2-3 weeks)
Consult information sources: managers, software engineers, end users…
Based on information collection (interviews, surveys, questionnaires…)
Should be short (2-3 weeks)

23. 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?

24. 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? …

25. Review
Software Requirements
Requirements Engineering Process

26. 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 (RG)
Software Requirements. Karl E. Wieger. Windows Press.
Dr. Gotel’s research web page
Dr. Barrett’s slides, NYU