Understanding Requirements

1
 Understanding Requirements: An Overview
 This topic is an overview of Requirements Engineering (RE), and RE is the initial part of huge area in
SE – Analysis, Design & Modeling/Testing/Prototyping/Simulation.

 CS&IS Dept. has the Requirements Engineering course (with a lot of details on RE including partially
UML language) for both undergrad and graduate students is available at the CS&IS curriculum.

 RE helps software engineers better UNDERSTAND customer needs, desires, requirements and
the problems they are trying to solve.
*) Building an elegant computer/software solution that ignores the customer’s
needs helps no one.

 It is very important to understand the customer’s wants and needs before you begin designing or
building a computer-based software solution.
*) Example: in Best Buy

 The intent of RE is to produce a written formal understanding of the customer’s problem using
prof. language of diagrams (not just in plain text form). Several outcomes might be used to
communicate this understanding, including:
- list of main users/actors,
- list of main functions and features,
- Use-Case scenarios (Use Case Diagrams, Activity Diagrams, SwimLane Diagrams, etc.),
- Data Objects (DOs) diagrams and Class Objects (COs) Diagrams,
- Data Flow Diagrams (DFDs), incl. Context DFD, Level-0 DFD, Level-1 DFDs, etc.,
- State Transition Diagrams (STDs),
- Entity-Relationships Diagrams (ERDs),
and many other possible Analysis Models. 2
 System Requirements Eng.: Analysis Model as a Bridge

System
Description
(by a customer)
List of system
specifications (SE
Diagrams that system
engineers and code
system
developers
description
understand)

analysis
model

design
model

Lists of requirements
to the system (that SW system
customer still development by
understands) code developers in
accordance with
SE Diagrams
3
IEEE Standard 729What is a Requirement in System Engineering?

Source: https://www.geeksforgeeks.org/software-engineering-classification-of-software-requirements 4
 Requirements Engineering: 6 Majors Steps (a summary)

 The software requirements engineering process has 6 distinctive steps:

1) inception (initiation, i.e. basic understanding of a problem, people who want a

solution; nature of desired solution, user environment, etc. ),
2) elicitation (drafting of requirements, possible approaches to solve problem,
technology, manpower, etc.),
3) elaboration (building aa professional analysis model, i.e. the way SE understood
what customer wants but using a professional language of diagrams),
4) negotiation (discussions/reviews with a customer),
5) problem specification (written documents/statements/diagrams/prototypes/
proposed specs, i.e. customer requirements using professional
language of SE diagrams), and
6) validation (review) of the proposed specifications (specs) with a customer and
professionals (i.e. coverage of essential features; clarity of
requirements and their details; sources for each requirement; potential
conflicts, etc.)

 RE must be adapted to the needs/specifics of a particular project, process, product, or

people doing the work.

 Remember: In some cases RE may be abbreviated (shortened), but it is

never abandoned. 5
System Requirements
Engineering: Main Strategies

1) OLD STYLE: a written document

with detailed identifies technical
specifications,

2) MODERN (VERY PROFESSIONAL)

STYLE: a set of graphical models –
diagrams (usually actively used by
mid-size and large size for large size
SW systems)

3) (AGILE STYLE): a working prototype

(probably with very limited – 5-10% -
number of all required/requested
functions) (usually actively used by
small size companies and for relatively
small SW systems
6
 Analysis Model:
Main Groups of Models to Create/Build
Analysis Model

1. Scenario-based models 2. Class-based models

(HOW this sytem will be used (WHAT are main components
By main groups of Users): ff the system):
- use-cases – textual; - class diagrams;
- use-cases – diagrams; - analysis packages;
- activity diagrams; - collaboration diagrams.
- swim lane diagrams;

4. Data-flow models
3. Behavioral models (WHARE main data and
(HOW system must react control flows between
to legal inputs from main components in the system) :
groups of legal Users: - data-flow diagrams;
- state transition diagrams; - ERD diagrams;
- sequence diagrams. - control-flow diagrams;
- processing narratives;

7
Understanding Requirements

Additional information

8
 Step 1: Inception (initiating RE process)
Inception—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 preliminary communication and collaboration between the customer and
the developer

Main activities on this step (ask millions of good professional questions) :

 Identify stakeholders (who are interested in such an application) and their viewpoints

 Questions of type A: Focus on customer, stakeholders, overall goals, and benefits of the system
 Who is behind the request for work?
 Who will use the solution?
 What will be the economic benefit of a successful solution?
 Is there another source for the solution needed?
 Questions of type B: Understand the problem and the customer’s perceptions of the solution
 How would you characterize good output form a successful solution?
 What problem(s) will this solution address?
 Can you describe the business environment in which the solution will be used?
 Will special performance constraints affect the way the solution os approached?
 Questions of type C: Focus on communication effectiveness
 Are you the best person to give “official” answers to these questions?
 Are my questions relevant to your problem?
 Am I asking too many questions?
 Can anyone else provide additional information?
 Should I be asking you anything else?
9
 Step 2: Eliciting (Drafting of) Requirements

 The goal is
 to identify the problem

 (if possible) to suggest quickly elements of the solution

 to negotiate different approaches, and

 to specify a preliminary set of solution requirements

 Collaborative requirements gathering guidelines

 Meetings attended by both developers and customers

 Rules for preparation and participation are established

 Flexible agenda is used

 Facilitator controls the meeting

 “Definition mechanism” (e.g. work sheets, stickers, flip sheets, electronic bulletin
board) used to determine (estimate) group consensus

10
 Step 2: Elicitation of Requirements:
An Algorithm (Sequence of Actions) using Activity Diagram in UML

Conduct FA ST
m eet ings

Make list s of
f unc t ions , classes

Make list s of
const raint s, et c.

f orm al priorit izat ion?

El i c i t re q u i re m e n t s
yes no

Use QFD t o inf orm ally def ine act ors

priorit ize priorit ize
requirem ent s requirem ent s

draw us e-cas e
writ e scenario
diagram

Creat e Use-c ases

com plet e t em plat e

11
 Step 2: Elicitation Work Products -- The Outcomes

 Needs: Statement of need and feasibility

 Scope: Bounded statement of scope for system or product
 Stakeholders : List of stakeholders involved in requirements elicitation
 Environment: Description of system’s technical environment
 Users: List of users (or, list of data objects) of deployed system
 Requirements: List of requirements organized by function and applicable
domain constraints
 Use-Cases: Set of usage scenarios (use-cases) that provide use
insight
into operation of deployed system
 Prototypes: Initial prototypes (sketches) developed to better
understand requirements

12
 Step 3: Elaboration (building an analysis model)
Analysis Modeling uses a combination of text and diagrammic forms to depict requirements
for
1) data,
2) functions, and
3) behavior
in a way that is relatively easy to understand, and, moreover, straightforward to review for
correctness, completeness, and consistency.

As a result, elements of the Requirements or Analysis Model

 Scenario-based elements
o Use-case - descriptions of the interaction between an “actor” and the system
o Functional - processing narratives for software functions
 Flow-oriented elements
o Data flow diagram (DFDs)
 Class-based elements
o Implied by scenarios (class elements, for example: Data Objects)
 Behavioral elements
o State transition diagrams (STDs)

13
 Step 3: Main Components of the SW Analysis Model

Analysis Model

2. Class models:
1. Scenario-based models: - class diagrams;
- use-cases – textual; - analysis packages;
- use-cases – diagrams; - collaboration diagrams.
- activity diagrams;
- swim lane diagrams;

4. Data-flow models:
3. Behavioral models: - data-flow diagrams;
- state transition diagrams; - ERD diagrams;
- sequence diagrams. - control-flow diagrams;
- processing narratives;

14
 Step 4: Negotiation with the Customer
(inform about your current understanding of a problem and
ask additional questions if needed)

 Goal is to produce a win-win result before proceeding to subsequent

software engineering activities

 Intent is to develop a project plan that meets stakeholder needs and real-world
constraints (time, budget, people) placed on the software team

 Negotiation activities
 Identification of system key stakeholders
 Determination of stakeholders’ “win conditions”
 Negotiate to reconcile stakeholders’ win conditions into “win-win” result for all
stakeholders (including developers)

15
 Step 5: Problem Specification

It has several meanings in Software

Engineering
due to type, nature and size of SW project, for
example:

1) OLD STYLE: a written document with

detailed identifies technical specifications,

2) MODERN (VERY PROFESSIONAL)

STYLE: a set of graphical models –
diagrams,

3) (INTRO STYLE) a collection of usage

scenarios (use cases),

4) (AGILE STYLE) a prototype,

etc.

16
 Step 6: Validating Requirements (1/2)

SE must be sure that engineered (designed and developed) requirements will provide QUALITY –
i.e. they will provide clear, precise and concise information/data for the Software Development
team, including the following:

 GOAL. Is each requirement consistent with the overall objective for the system/product?

 LEVEL OF DETAILS. 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?

 COVERAGE OF ESSENTIAL FEATURES. Is the requirement really necessary or does it

represent an add-on feature that may not be essential to the objective of the system?

 CLARITY OF REQ. Is each requirement bounded and unambiguous?

 SOURCES FOR EACH REQ. Does each requirement have attribution? That is, is a source
(generally, a specific individual) noted for each requirement?

 POTENTIAL CONFLICTS. Do any requirements conflict with other requirements?

17
 Step 6: Validating Requirements (2/2)

 ACHIEVABLE REQ. Is each requirement achievable in the technical environment that will house
the system or product?

 TESTABLE REQ. Is each requirement testable, once implemented?

 CORRECTNESS OF REQ. Does the requirements model properly reflect the information, function
and behavior of the system to be built.

 PARTITIONING OF REQ. Has the requirements model been “partitioned” in a way that exposes
progressively more detailed information about the system.

 SIMPLICITY OF REQ. Have requirements patterns been used to simplify the requirements model.
Have all patterns been properly validated? Are all patterns consistent with customer requirements?

18