Requirements and Analysis Workflows

What must the new product be able to do?

Object-Oriented & Classical Software Engineering, 7th Ed.

Stephen Schach, 2007
McGraw-Hill International Edition

Outline
Requirements Workflow

Analysis Workflow
Requirements Requirements Engineering Activities Modeling the Requirements
(separate slides) (separate slides)

Validation the Requirements

Requirements Workflow
Objective:
To determine the clients needs and constraints

Tasks:
Understand the application domain
Build a business model

Definition of Terms
Concept Exploration
Preliminary investigation of the clients needs

Application Domain
The specific environment in which the target product is

to operate or to be used, e.g., banking, military

Business Model
A document (containing UML diagrams) to describe the

clients business processes

Domain Analysis
Domain
The general field of business or technology in which the

customers expect to be using the software

Domain Analysis involves learning background knowledge to enable the software engineer to:
Communicate with users Be able to understand the problem Be able to make intelligent decisions

Lethbridge and Laganiere, 2005

Domain Analysis
Sources of information
Domain experts or people who work in a domain and

who have a deep knowledge of it Books about the domain Existing software on the domain and its documentation

Describe sources of information you can think of that can be consulted in order to perform domain analysis in <domain> Outline a short description of the information that you would need to gather in order to perform analysis for <system>

Lethbridge and Laganiere, 2005

Analysis Workflow
Objective:
To analyze and refine the requirements to achieve

the detailed understanding of the requirements essential for Developing a software product correctly Maintaining the software product easily
To specify product requirements using more

precise (or technical) language

Problem Definition and Scope

What is a Problem?
A difficulty the users or customers are facing
An opportunity that will result in some benefit such as

improved productivity or sales

What is a Solution? Entails software development, or purchasing a software

Lethbridge and Laganiere, 2005

Requirement
A feature of the software or a description of

something the software is capable of doing in order to fulfill the systems purpose (Old INTROSE
Slides)

A statement about what the proposed system

will do that all stakeholders agree must be made true in order for the customers problem to be adequately solved (Lethbridge and Laganiere, 2005)

Types of Requirements
Functional Requirement
Describes an interaction between the software and

its environment (Old INTROSE Slides) Describes what the system should do or the services provided for the users or other systems

Lethbridge and Laganiere, 2005

Types of Requirements
Categories of Functional Requirement
What inputs (data and commands) should the system accept

and under what conditions? What outputs (screen, printer, I/O devices, servers) should the system produce and under what conditions? What data should the system store that other systems might use? What computations should the system perform? The timing and synchronization of the above, if applicable

Lethbridge and Laganiere, 2005

Types of Requirements
Non-functional Requirement
Describes restriction on the software that limits

the choices for constructing a solution to the problem (Old INTROSE Slides) Constraints that must be adhered to during development Limits the resources that can be used Sets bounds on aspects of the softwares quality

Lethbridge and Laganiere, 2005

Non-Functional Requirements
Constraints on the design to meet the specified levels of

quality
Response time Throughput e.g., transactions or computations per minute Resource usage Reliability

Availability
Recovery from failure

Allowances for maintainability and enhancement

Allowances for reusability

Lethbridge and Laganiere, 2005

Non-Functional Requirements
Constraints on the environment and the technology of the

system
Platform Technology to be used

Constraint on the project plan and development methods

Development process (methodology) to be used, e.g.,

specific testing approaches Cost and delivery date

Lethbridge and Laganiere, 2005

Example
Functional Requirements
The software should allow different types of files to be

accessed. The software should print student grades.

Non-functional Requirements
Reliability: The software should inform the user if a file

type is not supported (instead of terminating abruptly or hanging). Response Time: The software should print student grades in 30 seconds.

Old INTROSE Slides

Levels of Functional Requirements

Business Requirements
Describe why the software is being built
Identify the benefits both customers and business

organization will reap from the software Help the company operate more efficiently (for information systems) or compete successfully in the marketplace (for commercial products)

Wiegers, 2003

Levels of Functional Requirements

User Requirements
Describe the tasks or business processes a user will

be able to perform with the software Modeled using use case diagrams
Functional Requirements
Describe the specific system behaviors that must

be implemented into the software to enable the users to accomplish their task

Wiegers, 2003

Levels of Functional Requirements

System Requirements
Describe the top-level requirements for a product

that contains multiple subsystemsthat is, a system A system can be all software or it can include both software and hardware subsystems People are a part of a system, too, so certain system functions might be allocated to human beings

Wiegers, 2003

Non-Functional Requirements
Business Rules Corporate policies, government regulations, industry standards, accounting practices, and computational algorithms They exist outside the boundaries of any specific software system They often restrict who can perform certain use cases or dictate that the system must contain functionality to comply with the pertinent rules

Wiegers, 2003

Non-Functional Requirements
Quality Attributes Augment the description of the product's functionality by describing the product's characteristics in various dimensions that are important either to users or to developers These characteristics include usability, portability, integrity, efficiency, and robustness

Wiegers, 2003

Non-Functional Requirements
Constraints Impose restrictions on the choices available to the developer for design and construction of the product
External Interfaces between the system and the

outside world (user, another software, and/or hardware devices)

Wiegers, 2003

Software Feature
A set of logically related functional requirements Provides a capability to the user Enables the satisfaction of a business objective

Wiegers, 2003

Example: Word Processor

Business requirement:

The product will allow users to correct spelling errors in a document efficiently.
What are its features?

What are its user requirements?

What are its functional requirements?

What quality attributes should it provide?

Wiegers, 2003

Example: Word Processor

Product feature:
Spell checker

User requirements (tasks or use cases to support the product

feature):
Find spelling errors Add word to global dictionary

Quality attribute
Usability Efficiency
Wiegers, 2003

Example: Word Processor

Functional requirements or operations:
Finding a misspelled word

Highlighting a misspelled word

Displaying a dialog box with suggested replacements

Globally replacing misspelled words with corrected

words

Wiegers, 2003

Requirements Development

Requirements Elicitation
Process of discovering the clients requirements

Communication-intensive process
The most difficult part is helping users figure out

what they want Methodology:

Interview

Survey or questionnaire

Observation
Document review (forms, reports)

Document Review
Obtain copies of all input forms, both filled in and blank, and all

output reports, if possible.

How often it is produced?

How many copies are generated?

Who receives the copies?

Study the existing system documentation. Deliverables that were performed Policy manuals and specifications of procedures, programs, data, and interfaces Written manuals and help files embedded in the software Negative documentation such as system errors, employee complaints

The documentations age is a clue to its reliability.

Old INTROSE Slides

Observation
Observe the current procedures.
Real operation vs. theoretical procedures written in the

documents Obtain permission from both the person to be observed and that persons supervisor; and explain the purpose Observe normal procedures and exceptional cases Participatory Observation
Stay out of the way, making certain we do not interrupt or

disturb the activities in progress.

Old INTROSE Slides

Requirements Analysis
Problem identification and analysis Process of refining and extending the initial set

of requirements elicited from the client Organizational/process modeling Systems analysts (or Business analysts) focus on what, not how

Old INTROSE Slides

Requirements Analysis
The Myth of Stable Requirements First law of system engineering [Bersoff]:
No matter where you are in the system life cycle,

the system will change, and the desire to change will persist throughout the life cycle.

Users dont know what they want.

Old INTROSE Slides

Requirements Analysis
The Myth of Complete and Consistent Requirements
Large systems are viewed as wicked problems:
Diverse user community with different priorities
Users are not the people who pay for the system

Old INTROSE Slides

Common Risks in Requirements Development

Insufficient User Involvement
Misunderstanding or lack of understanding of the

domain or the real problem Requirements churn requirements change rapidly Conflicting Requirements Creeping Requirements Ambiguous Requirements Gold plating Overlooked user classes
Wiegers, 2003; Lethbridge and Laganiere, 2005

Requirements Specification
A document that describes the system to be

developed in a format that can be reviewed, evaluated, and approved in a systematic way
(Cleland-Huang, 2005)

Constitutes a contract

Should not include imprecise terms like suitable,

convenient, ample, enough, etc. Essential for both testing and maintenance In the Unified Process, a set of UML artifacts constitute the specification document

Software Requirements Specification (SRS)

Used to document functional and nonfunctional

requirements Describes as fully as necessary the expected behavior, performance goals, and quality attributes of the software system Used in development, testing, quality assurance, project management, and related project functions

Old INTROSE Slides

Requirements Specification
Common problems:
Ambiguous two or more different interpretations

or meanings Incomplete missing some relevant fact or requirement Contradictions

References
Jane Cleland-Huang, 2005. Software Requirements. IEEE

Software Engineering, 3rd ed., Volume 1. T. Lethbridge & R. Laganiere, 2005. Object-oriented Software Engineering: Practical Software Development using UML and Java. London: McGraw-Hill I. Sommerville, 2004. Software Engineering, 7th ed. Pearson Education Karl Wiegers, 2003. Software Requirements, 2nd ed. Washington: Microsoft Press.