CHAPTER THREE

Requirements analysis and specification -

modeling techniques

1
 Stages in RE
• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Management

2
 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
– the effectiveness of preliminary communication
and collaboration between the customer and the
developer

3
 Elicitation
• elicit requirements from all stakeholders
– address problems of scope
– address problems of understanding
• customers are not sure about what is needed,
skip “obvious” issues, have difficulty
communicating with the software engineer,
have poor grasp of problem domain
– address problems of volatility (changing
requirements)

4
 Elaboration and negotiation
• Elaboration: create an analysis model that identifies data,
function, features, constraints and behavioral requirements

• Negotiation: agree on a deliverable system that is realistic for

developers and customers
– rank requirements by priority (conflicts arise here …)
– identify and analyze risks assoc. with each requirement
– “guestimate” efforts needed to implement each requirement
– eliminate, combine and / or modify requirements to make
project realistic

5
 Specification
• can be any one (or more) of the following:
– A written document
– A set of models
– A formal mathematical model
– A collection of user scenarios (use-cases)
– A prototype

6
 Validation
• a review mechanism that looks for:
– errors in content or interpretation
– areas where clarification may be required
– missing information
– inconsistencies (a major problem when large
products or systems are engineered)
– conflicting or unrealistic (unachievable)
requirements
– tests for requirements

7
 Management
• involves managing change:
– Feature traceability: how requirements relate to
observable system/product features
– Source traceability: identifies source of each
requirement
– Dependency traceability: how requirements are
related to each other
– Subsystem traceability: categorizes requirements
by the sub system (s) they govern
– Interface traceability: how requirements relate to
both external and internal system interfaces

8
 Methods and tools
many of them available
• lists
– elicitation question list
– checklists for validation
• graphical diagrams, good for communication
• formal methods
– e.g. UML for elaboration and specification

9
 Quality Function Deployment
A technique of translating customer needs into technical
system requirements:
• Normal requirements: reflect stated customer goals
and objectives
• Expected requirements: implicit to the product or
system; their absence will cause significant customer
dissatisfaction
• Exciting requirements: featured going beyond
customer expectations, causing customer euphoria (;-)
• concentrate on maximizing customer satisfaction

10
 Cont…
• Function deployment: determines the “value” (as
perceived by the customer) of each function required
of the system
• Information deployment: identifies data objects and
events, ties them to functions
• Task deployment: examines the behavior of the
system
• Value analysis: determines the relative priority of
requirements

11
Modeling approaches

12
 Requirements Analysis
13

 Requirements Analysis, determining whether the

stated requirements are clear, complete, consistent
and unambiguous.
 Requirements Analysis
14

 Stakeholder Identification
 Stakeholders are people or organizations that have a valid
interest in the system. They may be affected by it directly or
indirectly.
 Stake holders may include:
 Anyone who operates the system
 Anyone who benefits from the system
 Anyone involved in purchasing or procuring the system
 People opposed to the system (negative stakeholders)
 Organizations responsible for the system
 Requirements Analysis
15

 Stakeholder Interviews
 Interviews are a common technique used in requirement
analysis.
 This technique can serve as a means of obtaining the highly
focused knowledge from different stakeholders perspectives
 Requirements Analysis
16

 Types of Requirements:
 Customer Requirements:
 Operational distribution or deployment: Where will the system be
used?
 Mission profile or scenario: How will the system accomplish its
mission objective?
 Performance and related parameters: What are the critical system
parameters to accomplish the mission?
 Utilization environments: how are the various system components
to be used?
 Effectiveness requirements: How effective or efficient must the
system be in performing its mission?
 Operational life cycle: How long will the system be in use by the
user?
 Environment: what environments will the system be expected to
operate in an effective manner?
 Requirements Analysis
17

 Types of Requirements:
 Architectural Requirements:
 A formal description and representation of a system, organized
in a way that support reasoning about the structure of the
system which comprises system components, the externally
visible properties of those components, the relationships and
the behavior between them, and provides a plan from which
products can be procured and systems developed, that will work
together to implement the overall system.
 Requirements Analysis
18

 Types of Requirements:
 Functional Requirements:
 Defines functions of a software system or its components. They
may be calculations, technical details, data manipulation and
processing and other specific functionality that define “what a
system is supposed to accomplish?”
 They describe particular results of a system.
 Functional requirements are supported by Non-functional
requirements.
 Requirements Analysis

19

 Types of Requirements:
 Non-Functional Requirements:
 They are requirements that specify criteria that can be used to judge
the operation of a system, rather than specific behavior.
 Functional requirements define what the system is supposed to do,
whereas non-functional requirements define how a system is
supposed to be.
 Non-functional requirements can be divided into two main
categories:
 Execution qualities, such as security and usability, which are
observable at runtime.
 Evolution qualities, such as testability, maintainability and
scalability.
 Requirements Specifications
20

 Requirements Specification is the direct result of a

requirement analysis and can refer to:
 Software Requirements Specification
 Hardware Requirements Specification
 Requirements Specifications
21

 A Software Requirements Specification (SRS) –is a

complete description of the behavior of a system to
be developed.
 It includes a set of use cases that describe all the
interactions the users will have with the software. In
addition to use cases, the SRS also contains non-
functional requirements (such as performance
requirements, quality standards, or design
constraints)
 Requirements Specifications
22

 A Software Requirements Specification (SRS)

 The software requirement specification document enlists all
necessary requirements for project development. To derive the
requirements we need to have clear and thorough understanding of
the products to be developed.
 A general organization of an SRS is as follows:
 Introduction
 Purpose, Scope, Definitions, System Overview, References
 Overall Description
 Product Perspective, Product functions, User characteristics,
constraints, assumptions and dependencies.
 Specific Requirements
 External Interface requirements, functional requirements,
performance requirements, design constraints, logical database
requirement, software system attributes.
 Requirements Validation and Verification
23

 Validation (& Verification), is the process of checking

whether the requirements, as identified, do not
contradict the expectations about the system of
various stakeholders and do not contradict each
other.
 It is Requirements Quality Control
 Validation Vs. Verification
24

 Validation: “Am I building the right product?”

checking a work product against higher-level work
products or authorities that frame this particular
product.
 Requirements are validated by stakeholders

 Verification: “Am I building the product right?”

checking a work product against some standards and
conditions imposed on this type of product and the
process of its development.
 Requirements are verified by the analysts mainly
 Requirements management
25

 Requirements management is the process of

managing changing requirements during the
requirements engineering process and system
development
 Requirements are inevitably incomplete and
inconsistent
 New requirements emerge during the process as business
needs change and a better understanding of the system is
developed
 Different viewpoints have different requirements and these are
often contradictory
 Requirements change
26

 The priority of requirements from different

viewpoints changes during the development process
 System customers may specify requirements from a
business perspective that conflict with end-user
requirements
 The business and technical environment of the
system changes during its development
 Requirements evolution
27

Initial Changed
understanding understanding
of problem of problem

Initial Changed
requirements requir ements

Time
 Requirement Management
28

 Set of activities that help project team to identify, control, and track
requirements and changes as project proceeds
Requirements begin with identification. Each requirement is assigned a unique
identifier. Once requirement have been identified, traceability table are
developed.
Traceability Table:
 Features traceability table - shows how requirements relate to customer
observable features
Source traceability table - identifies source of each requirement

Dependency traceability table - indicate relations among requirements

Subsystem traceability table - requirements categorized by subsystem

Interface traceability table - shows requirement relations to internal and

external interfaces
It will help to track, if change in one requirement will affect different aspects of
the system.
 System models
29

 Different models may be produced during the

requirements analysis activity
 Requirements analysis may involve three
structuring activities which result in these
different models
 Partitioning. Identifies the structural (part-of)
relationships between entities
 Abstraction. Identifies generalities among entities
 Projection. Identifies different ways of looking at a
problem
The analysis model is composed of three individual
 models: 30
1. Functional model , represented by use cases and scenarios
2. Analysis object model , represented by class and object diagrams
3. Dynamic model , represented by statechart and sequence
diagrams.

Fig. The analysis model is composed of the functional model, the

object model, and the dynamic model.
 Analysis Model
31

Use case diagram

 Derived from use-case study scenarios. It is an
overview of use cases, actors, and their
communication relationships to demonstrate how the
system reacts to requests from external users. It is
used to capture system requirements.
Sequence diagram
 Describes time sequence of messages passed among
objects in a timeline
 Cont.…
32

Collaboration Diagram
 Describes the sequence of message passing among objects in
the system. Equivalent to sequence diagram , except that it
focuses on the object—s role.
 Each communication link is associated with a sequence order
number plus the passed messages.
Class Diagram
 Class diagrams can be derived from use-case diagrams or
from text analysis of the given problem domain. A class
diagram is
 generated by system analysts and designers and will be
iteratively refined in the subsequent phases during the
software development life cycle.
 Cont.
33

Activity Diagram
 Outline of activity—s data and control flow among
related objects. An activity is an action for a system
operation or a business process, such as those
outlined in the use-case diagram.
 It also covers decision points and threads of complex
operation processes. It describes how activities are
orchestrated to achieve the required functionality.
 Design Models
34

State chart diagram

 Describes the life cycle of objects using a finite state
machine.
 The diagram consists of states and the transitions between
states. Transitions are usually caused by external stimuli or
events. They can also represent internal moves by the
object.
Component diagram
 It is an Describes all components in a system, their
interrelationships, interactions, and the interface of the
system. It is an outline of the composition structure of
components or modules
 Cont.
35

Deployment Diagram
 Describes system hardware, software, and network
connections for distributed computing.
 It covers server configuration and network
connections between server nodes in real-world
setting.
Use case Diagram
36
Sequence Diagram
37
Collaboration diagram
38
Class Diagram
39
Activity Diagram
40
State Diagram
41
Component Diagram
42
Deployment Diagram
43
 SEG3101 (Fall 2010)

User Requirements Notation (URN)

Introduction to the User Requirements
Notation (URN)
 URN Overview (1)
 URN is a semi-formal, lightweight graphical language for
modeling and analyzing requirements in the form of
goals and scenarios and the links between them
 Combines two existing notations
 Goal-oriented Requirement Language (GRL)
 Use Case Maps (UCMs)

 Support for the elicitation, analysis, specification, and

validation of requirements
 Allows systems, software, and requirements engineers to
discover and specify requirements for a proposed system
or an evolving system, and analyse such requirements for
correctness and completeness

46
 URN Overview (2)
 URN models can be used to specify and analyze
various types of reactive systems, business processes,
and telecommunications standards
 jUCMNav
 URN editor & analysis tool
 Eclipse plug-in
 Open source project

47
 URN Overview
vision (3)
GRL Model business goals, called
stakeholders’ priorities, alternative strategies,
compared
solutions, rationale, and decisions with GRL
evaluation
traceability mechanis
with URN extensible
with m
links metadata
with UCM
traversal
UCM Model & test use cases; mechanis
m based
investigate high level architecture; on UCM
transform to more detailed models scenario
definitions

more detailed models

A GRL / UCM model visually communicates business objectives and

constraints / high-level functional requirements to all stakeholders
 Combination of Goals and Scenarios

 URN combines two complementary parts:

 The Goal-oriented Requirement Language (GRL)
 For modelling goals and other intentional concepts (mainly for non-
functional requirements and quality attributes.
 The Use Case Map (UCM) notation
 For modelling scenario concepts (mainly for operational
requirements, functional requirements, and performance and
architectural reasoning)

 URN offers concepts for the specification of stakeholders,

goals, non-functional requirements, rationales,
behaviour, scenarios, scenario participants (actors), and
high-level architectural structure

49
 URN – Main Objectives

 Focus on early stages of development with goals and

scenarios
 From user requirements to functional and non-
functional system requirements
 No messages, components, or component states required
 Reusability
 of argumentations (goal patterns and analysis)
 of scenarios (patterns and architectural alternatives)
 Early performance analysis
 Traceability and transformations to other languages
 Particularly MSC, SDL, TTCN, and UML
 Also to LQN, LOTOS, and others

50
 About ITU-T

 International Telecommunication Union

 United Nations organization
 191 countries + hundreds of member companies

 Free access to the definition of many standard languages

 http://www.itu.int/ITU-T/studygroups/com17/index.html
 Question 13 (Formal languages and telecommunication software) of
Study Group 17 (Security)
 Z.15x User Requirements Notation (URN)

 Also SDL, MSC, and profiles

 Other international bodies standardize languages

 ANSI (C, C++), W3C (HTML, XML), IEEE (VHDL), ISO (LOTOS),
OMG (UML), OASIS (XACML), etc.

51
 ITU Languages

 SDL: Specification and Description Language

 For defining and executing complete reactive systems

 MSC: Message Sequence Charts

 For defining message-oriented scenarios

 ASN.1: Abstract Syntax Notation One

 For defining data types/packets

 TTCN-3: Testing and Test Control Notation

 For defining test cases and test environments

 URN: User Requirements Notation

 Goal-oriented Requirements Language (GRL)
 Use Case Map notation (UCM)
 For defining abstract goals, scenarios, and requirements

 UML 2.0 profiles for some of these languages on their way…

52
 Transformations
 Transformations connect URN models to other models
 Some transformations discussed in publications or
implemented in jUCMNav’s predecessor UCMNav have not
yet been implemented in jUCMNav Requirements
Management
 Test Cases (Fitnesse, TTCN) (Telelogic DOORS)
 UML activity/sequence/state/use case diagrams

 SDL
Textual Use Cases User Requirements Notation Core Scenario
(jUCMNav) Model
(UCEd *)
(CSM)
(for performance modeling)

Message Sequence
Charts
(MSC Viewer)
 Summary

 The User Requirements Notation (URN) is an ITU-T standard

 Modeling with the Goal-oriented Requirement Language
 Focuses on answering “why” questions
 Intentions, functional / non-functional requirements, rationales

 Modeling with Use Case Maps

 Focuses on answering “what” questions
 Scenarios, services, architectures

 While modelling with URN as a whole, goals are

operationalized into tasks, and tasks are elaborated in
scenarios (mapped to UCM path elements)
 Moving towards answering “how” questions
 Can guide the selection of an architecture or scenarios
 Enables the elicitation/specification of systems, standards, &
products, analysis from various angles, & transformations

54
 GRL Editor with Strategy Evaluation
Toolba
r

Navigator Editor
view

Outline
view
Palett
e

Propertie
Scenarios and s
Strategies view
view
 UCM Editor with Scenario Traversal Perspectiv
e

Graphica
l Outline

Problem
s view
Integrated MSC Viewer for Exported UCM Scenarios

MSC
viewer

Outline
view
 SOFTWARE DOCUMENTATION

Discussion Topics
1. Introduction
2. Documentation Requirements
3. Process and Product Documentation
4. Document Quality
5. Standards
 Introduction

 This class provides an overview of the

 Reasons for software documentation

 Types of software documentation

 Documentation Requirements

 General requirements of all software documentation

 Should provide for communication among team members
 Should act as an information repository to be used by
maintenance engineers
 Should provide enough information to management to allow
them to perform all program management related activities
 Should describe to users how to operate and administer the
system
 Documentation Requirements

 In all software projects some amount of

documentation should be created prior to any code
being written
 Design docs, etc.
 Documentation should continue after the code has
been completed
 User’s manuals, etc.

 The two main types of documentation created are

Process and Product documents
 Process Documentation

 Used to record and track the development process

 Planning documentation

 Cost, Funding tracking

 Schedules

 Standards

 Etc.

 This documentation is created to allow for successful

management of a software product
 Product Documentation

 Describes the delivered product

 Must evolve with the development of the software

product

 Two main categories:

 System Documentation

 User Documentation
 Product Documentation

 System Documentation
 Describes how the system works, but not how to operate it

 Examples:
 Requirements Spec
 Architectural Design
 Detailed Design
 Commented Source Code
 Including output such as JavaDoc
 Test Plans
 Including test cases
 V&V plan and results
 List of Known Bugs
 Product Documentation

 User Documentation has two main types

 End User

 System Administrator

 In some cases these are the same people

 The target audience must be well understood!
 Product Documentation

 There are five important areas that should be

documented for a formal release of a software
application
 These do not necessarily each have to have their own
document, but the topics should be covered thoroughly
1. Functional Description of the Software
2. Installation Instructions
3. Introductory Manual
4. Reference Manual
5. System Administrator’s Guide
 Document Quality

 Providing thorough and professional documentation

is important for any size product development team

 The problem is that many software professionals lack

the writing skills to create professional level
documents
 Document Structure

 All documents for a given product should have a similar

structure
 A good reason for product standards
 The IEEE Standard for User Documentation lists such a
structure
 It is a superset of what most documents need
 The authors “best practices” are:
1. Put a cover page on all documents
2. Divide documents into chapters with sections and
subsections
3. Add an index if there is lots of reference information
4. Add a glossary to define ambiguous terms
 Standards

 Standards play an important role in the

development, maintenance and usefulness of
documentation
 Standards can act as a basis for quality
documentation
 But are not good enough on their own
 Usually define high level content and organization
 Standards

 IEEE
 Has a published standard for user documentation

 Provides a structure and superset of content areas

 Many organizations probably won’t create documents

that completely match the standard
 Standard Templates
71

 Ensures that all the essential information is included

 A number of different large organizations such as the US

Department of Defense and IEEE have defined standards for
requirements documents
 Probably the most acceptable of these standards is the IEEE/ANSI
830-1993
 The standard recognizes differences between systems, and allows
for some variations in the structure.
 There is a list of stable and variant parts:

 Stable parts
 Variant parts
 IEEE/ANSI 830 - 1993
72

1. Introduction:
 Purpose of the requirements document
 Scope of product
 Definitions, acronyms and abbreviations
 References
 Overview of the remainder of the document

2. General Description:
 Product perspective
 Product functions
 User characteristics
 General constraints
 Assumptions and dependencies
 IEEE/ANSI 830 - 1993

3. Specific Requirements
 Covering functional, non functional & interface requirements,
these should document
 External interfaces
 Functionality
 Performance requirement,
 Logical database requirement,
 Design constraints,
 System attributes
 Quality characteristics
 IEEE/ANSI 830 - 1993

4. Appendices
5. index
 75

Thank You!
Q?