CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Chapter 7
Requirements Engineering
Elements of software requirement gathering
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
What is Software Requirement?
“A software requirement is a description of the principle
features of a software product, its information flow, its
behavior, its attributes. In sum, a software requirement
provides a blueprint for the development of a software
product. The degree of understandability, accuracy, and rigor
of the description provided by a software requirement
document tends to be directly proportional to the degree of
quality of the derived product.”
Source: Software Engineering: An Engineering Approach, by James Peters
and Witold Predrycz, Wiley, 2000, Page 118.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Requirements Engineering
Goal: Better understanding of the problem at hand and business
impact of the system.
How is it done? Through a process that facilitates a set of
defined tasks.
Why do it? To establish a solid foundation for system design and
construction.
It is not the solution, but an approach to facilitate the
development of a effective solution.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
What is Software Requirements Analysis? - 1
Software requirements analysis is process of understanding
customer requirements of the software system to be built, and
building analysis model of the system (data, functions,
behaviour/control flow, interfaces).
The analysis model serves as
- basis for creating specifications and software design
- means for assessing the quality of the system to be built
This process requires active participation of the customer, and it
is crucial step in the development process. The analyst may
play different roles - interrogator, advisor, problem solver, and
negotiator.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
What is Software Requirements Analysis? - 2
The outcome of the process:
- Software Requirements Specifications (SRS). The SRS
should be clear, complete, and consistent with customer
needs.
- Quality Assurance Plane - set of activities that the project
team can follow to ensure software quality throughout the
product life cycle (portability, reliability, efficiency, V&V criteria,
cost, acceptance criteria, etc…)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
System vs. Software Requirements
System requirements analysis, in part, focus on how the
software element interacts with other elements of the system
(constraints and limitations).
Software requirements analysis focus on the data, functional,
and behavioural modeling of the software itself (OOA focuses
on classes, relations, and object behaviour modeling).
For software requirements analysis, try to fully answer the
following:
- What are the inputs and outputs?
- What functions should be defined?
- What behaviors (control activities) should be exhibited?
- What interfaces are needed?
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Why Do Requirements Analysis?
- Identify the customer and work together to negotiate productlevel requirements
- Build an analysis model (focus on data, define functions,
represent behaviour)
- Prototype areas of uncertainty in the system
- Develop a specification to guide the design and development
- Conduct formal technical reviews to ensure software quality
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
The Analysis Process
build a
prototype
the problem
requirements
elicitation
develop
Specification
create
analysis
models
Review
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Problem Analysis
Problem Analysis
Environment
- People
(operators and
users)
- Devices
- Other items
affected by the
system
- business
value
Products
- Inputs
- Outputs
- Items
produced
for the
system
Functions
- People
functions
- Device
functions
- Other
functions
needed to
produce
services
and items
Operations
- Methods
used
- operations
used to
produced
items
- When
operations
occur
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Real Problems…
- the customer has only a vague idea of what is required.
- the customer keeps changing requirements.
- the software engineer (analyst) is willing to proceed with the
vague idea on the assumption that we'll fill in the details as we
go.
- the software engineer (analyst) is affected by the changes,
making errors in the specifications.
- ?
- ?
- and so it goes ...
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Requirements Engineering Work Tasks - 1
• Inception: Starting the project… where to star?
Ask a set of questions that establish
-
basic understanding of the problem
the people who want a solution
the nature of the solution that is desired, and
the effectiveness of initial communication and
collaboration between the customer and the developer
• Elicitation: Elicit requirements from all stakeholders
• Elaboration: Modeling and refinement (chapter 8) - create
analysis model that identifies data, function, and behavioral
requirements. (in OOA, analysis classes, their services, their
relationships).
• Negotiation: Agree on a deliverable system that is realistic for
developers and customers.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Requirement Engineering Work Tasks - 2
• Specification: Can be any one (or more) of the following:
–
–
–
–
–
A written document
A set of models
A formal mathematical
A collection of user scenarios (use-cases)
A prototype
• Validation: A review mechanism that looks for
–
–
–
–
–
–
Errors in content or interpretation
Areas where clarification may be required
Missing information
Inconsistencies (a major problem with large systems)
Conflicting or unrealistic (unachievable) requirements
Conformity issues (with standards set for the product, process,
project)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Requirement Engineering Work Tasks - 3
• Requirements management: A process to identify, control, and
track changes to requirements (similar to SCM)
Traceability tables facilitate requirements management
–
–
–
–
–
feature (of system) traceability table (see figure 7.1, page 148)
source (of requirements) traceability table
dependency (among requirements) traceability table
subsystem traceability table (categorization of requirements)
interface traceability table
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Inception – Start the project
• Identify stakeholders
– “who else do you think I should talk to?”
• Recognize multiple points of view
• Work toward collaboration (productive meetings)
• The first questions to ask:
– Who is behind the request for this work?
– Who will use the solution?
– What will be the economic benefit of a successful solution?
– Is there another source for the solution that you need?
– …
(see page 152)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Elicitation - 1
Initial interview:
- break the ice and establish communication channels
- scripted (context-free) questions may be used
• understand customer goals and scope the problem
• identify stakeholders interested in the system
Sample questions:
-
What do you expect of the new system?
How will the system help your organization?
Who will be using the system?
Will the system interact with other systems?
etc…
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Elicitation - 2
There is not one way for gathering requirements from the
client…
The meeting format determines its effectiveness and outcomes.
It is important to listen, but that is not enough! In addition to
meeting notes, recording the meetings may be required.
One approach is called Facilitated Application Specification
Techniques (FAST) . It is a team-oriented approach to
promote constructive and effective communications.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
FAST Approach
Guidelines:
•
•
•
•
•
•
•
participants must attend entire meeting
all participants are equal
preparation is as important as meeting
all pre-meeting documents are to be viewed as proposed
off-site meeting location is preferred. Why?
set an agenda and maintain it
focus on requirements and don’t get mired in technical details
Benefits: many points of view, instantaneous discussion and
refinement, concrete step toward developing specs.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Collaborative Approach
Guidelines: (in the textbook)
• Meetings are attended by both software engineers and
customers
• Preparation and participation rules are established
• Set an agenda
• Assign a facilitator (customer, developer, outsider) to manage
the meeting
• Utilize a "definition mechanism" (work sheets, flip charts, wall
stickers, E-bulletin board, chat room, or virtual forum)
The goal is to identify the problem, propose a solution, negotiate
different approaches, and specify a preliminary set of
requirements
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Quality Function Deployment (QFD)
Another approach for requirements gathering. Its purpose is to
maximize customer satisfaction while developing software
requirements that are valuable to the customer. It identifies
three types of requirements:
- Normal requirements: what the customer explicitly states
and wants in the system.
- Expected requirements: what the customer wants but did
not explicitly state assuming we know such requirements.
- Exciting requirements: additional features we can offer.
Check QFD Institute at http://www.qfdi.org/
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Elicitation Work Products
• a statement of need and feasibility (or statement of work).
• a bounded statement of scope for the system or product.
• a list of customers, users, and other stakeholders who
participated in requirements elicitation.
• a description of the system’s technical environment.
• a list of requirements (preferably organized by function) and
the domain constraints that apply to each.
• a set of usage scenarios that provide insight into the use of
the system or product under different operating conditions.
• any prototypes developed to better define requirements.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Use-Cases - 1
Another approach to requirement gathering is Use-cases. Use
case are scenarios of system usage by different actors
(classes of users and devices).
e.g., student, faculty, and registrar are actors for
student registration system.
- Uses-cases are used to:
- obtain requirements from the customer
- effectively express requirements to the customer
Annotated diagrams are common way to present use-cases.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Use-Cases - 2
Some of the questions a use-case should answer:
- What are the main functions performed by the actor?
- What information will the actor acquire, produce or change?
- What information does the actor desire of the system?
- others…
Check the article “Structuring Use Cases with Goals” at:
http://alistair.cockburn.us/
Structuring+use+cases+
with+goals
See example page 161.
Retrieve a file use-case
1. User clicks file menus
2. System displays options new and open
3. User clicks option open
4. System displays open file window
5. User enters/selects file name
6. User clicks open button
7. System retrieves and opens the file
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Analysis Principles - 1
Analysis methods may vary, but they share common principles:
1. Information Domain Analysis and Data modeling:
- define data (and control) items/objects
- describe data attributes
- establish data relationships and data structures
e.g., student transcript (data object) with different attributes.
2. Function modeling: (iterative process)
- identify functions that transform data objects
- indicate how data flow through the system
- represent producers and consumers of data objects
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Analysis Principles - 2
3. Behaviour modeling:
- indicate different states of the system
- specify events that cause the system to change state
4. Partitioning the model:
refine each sub-model to represent lower levels of abstraction
- refine data objects
- create a functional hierarchy
- represent behavior at different levels of details
5. The essence: focus on the problem (requirements) not the
implementation details (i.e., answer “what” questions).
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Validate Requirements - 1
• Is each requirement consistent with the overall objective for the
system/product?
• Have all requirements been specified at the proper level of
abstraction? That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?
• Is the requirement really necessary or does it represent an addon feature that may not be essential to the objective of the
system?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source
(generally, a specific individual) noted for each requirement?
• Do any requirement conflict with other requirements?
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Validate Requirements - 2
• Is each requirement achievable in the technical environment that
will house the system or product?
• Is each requirement testable, once implemented?
• Does the requirements model properly reflect the information,
function and behavior of the system to be built.
• Has the requirements model been “partitioned” in a way that
exposes progressively more detailed information about the
system.
• Have requirements patterns been used to simplify the
requirements model. Have all patterns been properly validated?
Are all patterns consistent with customer requirements?
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Deployment Practices
• Deployment involves system delivery, end-user support, and
feedback from end-users.
• Principles:
–
–
–
–
–
–
Manage customer expectations for each increment
A complete delivery package should be assembled and tested
A support group should be established before delivery
Instructional materials must be provided to end-users
Buggy software should be fixed first, delivered later
Encourage and collect customer feedback on the system
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Suggested Problems
Consider working the following problems from the end of
chapter 7, page 173, for practice purpose:
7.1, 7.2, 7.3, 7.4, 7.11, 7.13, 7.16, 7.17
No submission is required. Think about these problems and
work them for yourself!
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Last Slide
End of Chapter 7