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

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements

Non-functional requirements

• It is important to be able to test/verify/check non-functional requirements

Property MeasureSpeed Processed transactions/second

User/Event response timeScreen refresh time

Size K BytesNumber of RAM chips

Ease of use Training timeNumber of help frames

Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability

Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure

Portability Percentage of target dependent statementsNumber of target systems

Requirement engineering

• 5 important activities:– Feasibility study– Requirements elicitation and analysis– Requirements documentation– Requirements validation– Requirements management

Requirement engineering

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument

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