Chapter 5 Requirement Analysis

Chapter 5
Requirement Analysis &

Documentation
Structure
Introduction
y Requirement Analysis & documentation
y Tasks to be performed
y Requirements Elicitation
y Story board/Screen flows
y A case on requirement analysis
y Summary
y
Introduction
The Requirements of the business are
what drive application design &
development ,&its extremely important
that these requirement are met in your
design.
y The analysis of business requirement is
not an exact science in all cases.
y
Requirement Analysis & Documentation

Requirement Analysis & documentation
describes how stakeholders needs are
analyzed, structured and specified for use
in design & implementation of a solution.
y Deliverables from this process will be
used by the project team to develop
estimates for the time, resource & budget
requirement
y
Inputs to Requirement Analysis &

Documentation
The business analyst continues to refine the
overall scope of the problem domain &
scope of investigation.
y The business analyst and project team work
with stakeholders to conduct requirement
analysis.
y
Inputs to Requirement Analysis &

Documentation
The business analyst has defined a set of
deliverables that will be the outcome of
requirements documentation .
y They include
y
y Documentation
y Organizational assets
y Supplemental work record
Tasks to be performed For Requirement

Analysis & Documentation
Documenting requirements
y Determining the assumptions and
constraints.
y Structure requirements.
y Determine requirements attributes
y
Outputs of Requirement Analysis &

Documentation
Fully specified requirements are the primarily
output of this area.
y They are stable enough to be implemented by
project team.
y
Analysis techniques for Requirement

There are three broad types of solution
development techniques that BA use.
y Business process analysis
y Object-oriented analysis
y Structured analysis

y
Business process analysis

Business process analysis focuses on improving the
processes of an enterprise in order to maximize
the achievement of its business mission, objectives
and priorities.
Business process analysis projects employ a model
to describe both current process and
recommended future process.
10

Object-oriented analysis
y Views a information as a collection of classes
that pass messages to one another.
y Object-oriented modeling techniques are
supported by Unified Modeling Language
(UML)
y
11

y
Structured analysis views primarily a

collection of following process
Structure requirements packages
Create business model
Analyze User requirements
12
Task1 Structure Requirements Packages

The purpose of structuring requirements
into packages is to refine the problem
boundary and solution scope definitions
developed in enterprise analysis.
y This iteration continues until the
requirement have been structured.
y
13
Predecessors of Task Structure

Requirements Packages
The Business Analyst has determined the
scope of the problem domain as described in
enterprise Analysis.
y The Business Analyst conducts the tasks
defined in the requirements Elicitation area
y
14
Process & Elements of Task Structure

y
Define Solution Boundary

Where other actors interact
Where other systems provide
Where time initiates activities for solution
15

1 Goal Decomposition
Goals are developed by Stakeholders in the
enterprise area.
Goals are prioritized during the planning and
managing area.
Goals are business requirements
16

2 Features List Decomposition
Feature is a service that the solution provides to
fulfill one or more stakeholder needs.
Features can be textual or graphical
17

3 Functional Decomposition
Identifies the high-level functions of an
organization and breaks down them into subprocesses and activities.
Models start from top level function ,continue to
drill down into sub functions
18

4 Solution Driven Decomposition
y In some projects ,the solution architecture is
determined at the time of project initiation.
y Stakeholders are impacted by analysis
technique.
y The deliverables of this task is a
documentation
19
Task 2 Create Business Domain Model

The purpose of the Create business domain
model task is to describe the current and
future state of the enterprise.
y The objective is to create a complete
description of existing & proposed
organizational structure ,processes , and
information used by the enterprise
y
20
Process to Create Business Domain Model

y
Domain and User Variation

Multiple work units perform the same function.
Multiple users perform the same work
Resolution
The business analyst will document whether the
to be solution will accommodate the
inconsistencies in the current business model.
21
Task 3 Analyze User Requirement

The purpose of this task is to capture and
describe requirements that affect a particular
user & insure that needs of stake holders are
addressed by solution.
y They may be used to describe how a
particular set of users of solutions will
interact with it.
y
22
Predecessor Task
The process of analyzing and specifying user
requirement is identical to the processes
used to Analyze Functional requirements,
quality of service requirements and
constraints.
y The business analyst and other stakeholders
will be concerned with ensuring that conflicts
between sets of user requirements can be
resolved.
y
23
Task 4 Analyze Functional Requirement

The functional requirements are analyzed to
describe the desired behavior of a solution.
y Functional requirements describe the
behavior that the solution will manage.
y
24
Process & Elements to Analyze Functional

Requirement
The following are guiding principles in
analyzing functional requirement.
1. Textual Documentation
Some requirements are best stated in simple
textual sentences , for example business rules
1) Expressed as a verb or verb phrase
2) Avoid complex conditional clauses
cont
y
25

Requirement
Well formatted requirements
y A well-formed textual requirement must
describe capabilities of the solution .
y Each of following elements is considered
y
Event /Condition
Subject
Action Verb
26

Requirement
2. Matrix documentation
y Table is a simplex form of metrics
y A more complex matrix will also express
information in the rows of the table.
27

Requirement
3. Diagrams
y Diagrams are effective for showing the
relationship between items of information in
a requirement specification .
y Diagrams that are intend to show a
hierarchical relationship between elements of
the diagram should place most important
elements at top.
28

Requirement
4. Models
y The template for expressing the
requirements that may combine textual
elements, matrices, and diagrams is called as
Model.
y Business Analyst may choose to rule out
modeling when the problem domain is well
known.
Cont..
29

Requirement
As the complexity of a solution increases,
communication needs dictate modeling.
y The benefits of using modeling techniques
are
y
A model is simplification of reality.

Help us to understand & describe complex system
Models may easily translate into a solution design
y
..cont
30

Requirement
A model may be Formal , highly structured
and detailed or informal and general.
y Model view points
y
Out of the most commonly used sets of

viewpoints the development of separate Physical
and logical model is the in use.
31

Requirement
5. Related Task
y The Business analyst should execute
determine requirement attributes and
structure requirements for traceability in
parallel with this task.
y When analyzing a desired future state of
solution ,the products of the analysis efforts
must be validated with the project team.
32

Requirement
Task 5.
Analyze Quality of service Requirement
y Quality of service requirements captures the
Environmental conditions under which the
solution remains effective.
y Quality of service requirements are most
often used to describe some of the attributes
of the system.
33
Process & Elements to Analyze QOS

Requirements
Environmental Requirements
y Environmental constraints imposed by the
atmosphere outside of the system
boundaries.
y Audit information define information that
the process or system does not need in
normal course of events.
1.
34

Requirements
2. Interface Requirements
y
Interface requirement define the
interactions between computer systems.
y Hardware interface describes characteristics
of each interface between system &
hardware component.
y Software interface describes to other
component
35

Requirements
3. Glossary
y
Glossary is used by Project Team to
consistently use the terminology.
y
It provide definitions of common problem

domain terms to other project team
members
36

Requirements
4. Operational Requirement
y Operational Requirement define how the
system will run and interact with operators.
5. Performance Requirement
y It provide for various system component
indicate how much information the system
must be capable of processing in given
period of time.
37

Requirements
6. Privacy
y Privacy requirements restrict the
distribution of personal information.
y These may be in some cases be expressed
through business rules
7. Quality Requirement
y Quality Requirement describe the design
ability,reliability,usability,testabilty.
Cont
38

Requirements
Key quality requirements.
Failure and Disaster Recovery describes how the

system is to be secured against catastrophic
failure.
Maintainability requirement describe how likely
future changes the solution are and what should
be done to facilitate those future changes in the
present.
Scalability requirement describe the likely
growth
39

Requirements
Safety requirements.
8.
Safety requirements specify those requirements

that are concerned with possible loss ,damage,
or harm that could result from the use of
system.
9. Security requirement
Security requirement are important when the
nature of data that is traded is sensitive ,or
access to the information must be either
monitored.
40

Requirements
Safety requirements.
8.
Safety requirements specify those requirements

that are concerned with possible loss ,damage,
or harm that could result from the use of
system.
41

Requirements
10. Training requirement.
Training requirements describes the educational

needs of stakeholders who will interact with the
solution.
They describe the types of stakeholders affected.
42
Process & Elements to Determine

Assumptions & constraints
Task 6.
Determine Assumptions & constraints .
y Assumptions & constraints identify aspects of
problem domain that are not functional
requirements of a solution.
y Constraints are limitation or restriction on
solution.
Cont
43

Assumptions & constraints
There are two type of the constraints which
describes the limitations on the projects
flexibility
1) Technical constraints
2) Business constraint
y Assumptions are used to document two
types of issues relevant to the project.
y
44

Requirement Attribute
Task 7.
y Requirement Attribute provide information
about Requirement ,such as the source of
Requirement and other metadata.
y Predecessor Task
Which attribute that should be
documentated will be determined during
requirement planning.
Cont
45

y
1. Process
During Requirement Elicitation ,the Business
Analyst must record any information supplied by
stakeholders
2. Use of Imperatives
The Business Analyst may use imperatives to
describe the priority of each requirement
..Cont
46

3. Elements
y Some common requirement attributes
includes.
1) Urgency
2) Scalability
3) Complexity
4) Ownership
5) Status
y
47
Document Requirements
Task 8.
y The Business Analyst must create a
requirements document to facilitate a
common understanding of the requirements.
y Predecessor Task
Requirement documentation requires the
requirements Elicitation and analysis activities.
Cont
48
Process & Elements
Selecting & Document Format
y
The format of the requirements document is
likely to be determined by the methodology and
process adopted by the enterprise.
2. Common Document format
y
There are many terms for required documents.
y There are some common formats used for
particular software development
1.
.Cont
49
Process & Elements
Common Document format
y
Vision
y
Business Process Description
y
Business Requirements Document
y Request for proposal
y
Software Requirements specification
50
Process & Elements
Task 9 Validate Requirements
y
The purpose of this task is to ensure that the
stated requirements are correctly and fully
implement the Business Requirements as defined
during Enterprise analysis.
Task 10 Verify Requirements
y Requirements verification ensures that
Requirements are defined clearly enough to allow
solution design
51
Process & Elements
Predecessor Task
y
Validation represents a final check by the Business
Analyst to determine that the Requirements
analysis has correctly performed.
Process and Elements to verify Requirements
y
The Business Analyst must verify that
Requirements have been specified uniquely in wellwritten statements.
52
Process & Elements to verify Requirements

1.Criterion for Accessing requirements
Quality
1) A locatable
2) Complete
3) Attainable
4) Feasible
5) Traceable
6) Prioritized
7) Correct
8) Necessary
53

2. Check lists
y Checklists are useful as a quality control technique.
y The Business Analyst ,in conjunction with the
solution delivery team ,will have the primarily
responsibility for determine this task has been
completed
54

Technique: Data and Behavior Models
y
y
y
Data and Behavior models may be referred to as

Static models .
The statement that defines some aspect of the
business is called as Business Rule.
A Business rule is a statement that defines or
constraints some part of business
.. cont
55

Textual Rules :
y Common type of textual rules include
1) Term
2) Derivation
3) Assertions
4) Action enabler
5) Fact
56

y
Decision Tables :
Decision tables are used to structure the
presentation of series of closely related Business
rules .
Decision tables may also be used when multiple
rules may apply to solutions.
57

y
y
y
y
Decision Tables Example :

Decision tables for the policy followed by a
company in giving discount to its customer.
Transaction in credit
Transaction in cash
Discount offered
58

y
User Considerations :
The Business Rules Management may be used
whenever it is necessary to ensure that the policies
that constraint and direct the operation of a
business are well understood & correctly
implemented.
The strength of Business Rules Management is that
it provides a structured rigorous approach.
59

y
Complementary and alternative Technique :

The Business Rules may be encapsulated in
Process/Flow models ,a Metadata Definition or in a
Use case Description.
Class model :The purpose of class diagram is to
show the entities relevant to the solution ,along
with each entities internal structure.
60

y
y
Key features of Class model :

The format & element of the class diagram are
defined in UML standard.
A logical class model also makes it easier to build
and design system architecture is main strength of
class model.
Class models result from a object oriented analysis
and design approach may not be useful for non OO
solutions
61

Examples of Class model :
y Bicycle Objects
Bicycle Class
Attributes
Frame size
Color
Gears
y Create a class called Bank account
Attributes
Account No, Name, Current balance
62

y
CRUD Matrix :
The CRUD (Create, Read, Use , Delete ) technique
is used to define different levels of access rights to
data store within a software.
For each data element ,it states which user groups
are allowed to create ,read , use , delete entities.
63

y
Process to develop CRUD Matrix :

The CRUD (Create, Read, Update, Delete ) matrix
requires that the Business analyst identify sets of
user who have different access rights to the data
stored in the system.
The CRUD matrix also requires that a detailed data
model be defined for system.
64

y
y
y
y
Key features of CRUD Matrix :

Create: new instances of data element.
Read : View data stored
Update : change data stored.
Delete : Delete instances of Data
65

y
y
y
Usage considerations of CRUD Matrix :

The CRUD Matrix is intended for use in software
development projects and is unlikely to be much
value in Business Process Analysis.
The Business Analyst must be careful to keep the
CRUD matrix consistent with user group.
The information expressed in a CRUD Matrix is
also be captured in use case or in Business rules.
66

y
y
Data directory :
The data directory define the data that is recorded
or used by an organization.
It relates to the solution ,including both primitive
data elements & more complex data structure
67

y
Process to Create Data directory :

The data directory is collected throughout the
requirement Elicitation process by collecting by
definitions of terms.
Key features of Data directory
Primitive data elements

Name
Alias
Values
Description
68

y
y
Composite Data Elements

The Composite data is assembled from primitive
data element.
Composite Data Elements structure includes:
Sequence
Repetitions
Optional Elements
69

y
Usage considerations
The Data Dictionary is useful for ensuring that all
stakeholders in a solution in agreement on the
format and content of information.
The Business Analyst may choose to capture
business rules governing the data while the data
dictionary is complied.
70

y
y
y
y
y
The Data Dictionary Example

Sample Data Dictionary Entry for data element emp_code
Data element : emp_ code
Description : A unique code to employee
Type : Char
Range: 0001to 9999
71

y
The Data Transformation and Mapping

The Data Transformation and Mapping is used on
application development projects that require use of
existing business data records.
Variants on Data Transformation and Mapping
include:
Extraction
Transformation
Loading
.cont
72

y
y
y
y
The Data Transformation and Mapping

The Data Transformation and Mapping provides a
way for a project to understand several data
challenges like :
Different places : The data may lie in
heterogeneous systems at different places.
Different definition : The data may be defined
differently.
Varying level of quality :
73

Process for Data Transformation and Mapping
This process covers requirement planning activities.
y High level data modeling.
y Data analysis.
y Iterative Review of analysis model.
y Enterprise data model
. cont
74

Process for Data Transformation and Mapping
No matter what metrology is used, this process
must include following :
y High level data modeling.
y Data Business rules.
y Data cleansing plan
y Environment plan
y business data categories
75

Usage consideration
This is the early analysis phase of a project process
that allows a enterprise to develop analysis that
supports the plan to
y Move data from multiple sources.
y Reformat and cleanse it.
y Load to another database.
76

y
y
y
y
Complementary & Alternative Technique

Data Transformation and mapping process has no
alternative ,if data needs to be moved from source
system to target business system.
There may be tailoring of the project depends upon
size of the project.
Entity Relationship Diagram is a visual
representation of a data structure.
Business analyst use ER diagram to communicate
data requirements.
77

Process to Develop Entity Relationship
Diagram
y Identify what appears to be the things of
significance.
y Identify attributes of each entity & relationship
between them.
y Decide unique identifier for each entity.
y Validate model with Business analyst
78

Key features of Entity Relationship Diagram
y An ER diagram has four main components.
y Entities
y Attributes
y Unique Identifier
y Relationship
79

Entity Relationship Diagram
Places
Customer
Order
Is ordered
Product
Order Item
80

Usage Considerations
Logical ER diagram can be used by a Business analyst
to :
y Develop and document an understanding of the
entities of significance to business.
y At high level ,simplify and clarify complex problem.
y Document the data requirements.
81

Strengths of ER diagram
y Flexibility , in that they can be used at a high level.
y Rigor , in that they are based on mathematical
concept.
Weakness of ER diagram
y Complexity
y Data centric
82

y Entity Relationship Diagram should be supported by
business rules and metadata.
y ER diagram may be replaced with
Textual documents
Object role model
Class diagrams
Variations - Logical Data Models
83

Entity Relationship Diagram Example
T No
Name
Roll No
Teaches
Teacher
Address
v
Name
Student
Salary
Class
Name
Marks
Name
84

Metadata Definition
y Metadata is information about data used by a
solution that helps Business analyst to explain the
context in which data is used.
y The capture of metadata is normally a byproduct of
functioning of system.
y Metadata must eventually be recorded within the
solution to be of any value.
85

y
Metadata includes information that Business

Analyst is likely to capture in particular.
The structure of the primitive data element .
Ownership of the access to data element .
Business Rules
86

Technique :Process/Flow models
y
y
The process /flow model may also be described as

dynamic model.
These models show how the system behaves over
the course of time.
87

Activity Diagram
y
y
y
The purpose of Activity Diagram is to graphically

represent the flow of a sequence of activities
Activity Diagram is useful whenever it is necessary
to communicate complex process.
Standard: The format & elements of Activity
Diagram are defined by the UML standards.
88

Process to Make Activity Diagram
Completion of an Activity Diagram is generally
accomplished by
y Deciding boundaries
y Determining details of activities
y Completing Diagram
y Preparing textual description
89

Key features of an Activity Diagram
An Activity Diagram has following components.
y Activities represented by rounded rectangles
y Sequential flow of activities by arrow
y The start point by filled circle
y End point by bounded filled circle
90

Activity Diagram can be used
y Analyze and describe a complex Use case
y Analyze and document Business Work flow.
y Describe complex sequence of activities
91

Strengths of Activity diagram
y Ability to visualize complex flows .
y Easy to develop & understand by most users.
Weakness of Activity diagram
y Complex sequence of Activities ,difficult to
organize
92

y
There are number of other diagramming

conventions that serve similar purpose to activity
diagram. These include
The IDEF3diagram developed by U.S department.
Flowcharts
Workflow models
93

Activity diagram for order processing system
y The solid circle represents start of process.
y Rounded rectangle different activities.
y Arrows represents the triggers or events
y The horizontal bar represents activities which
occur in parallel
y
94

Data flow Diagram
To show how information is input , processed , stored
and output from a system is the purpose of DFD
y External entities that provide data to or receive
data from , a system
y The process of the system that transform data.
y Data store & flows to external entities.
95

Process of Data flow Diagram
Data flow Diagrams are prepared by successive
decomposition of a process.
Key Elements in DFD
y External entities represented as rectangle
y Data store represented as two parallel lines ___
y Data Process diagonal rectangle
y Data flow as arrows
96

Data Flow Diagram can be used
y DFDs are used as a part of Structured analysis
approach.
y They are used to get an understanding of range of
data within domain.
97

Strengths of DFD
y May be used as discovery technique for process of
data.
y Most users find easy to understand.
Weakness of DFD
y May not be the most useful analysis to developers
in a structured programming environment.
Complementary technique
The DFD conveys similar information to that found in
Activity Diagram ,Work flow diagrams
98

Context Diagram for payroll System
Bank
Employees
Payroll
system
Accounts Department
99

Example case Railway Reservation System
Passenger
Reservation
Booking Clerk
Tickets
System
Accounts Department
100

Event Identification
Event identification technique facilitates the discovery
of the processes.
y External events are initiated by an entity that is
external to the system.
y Temporal events are initiated by Passage of time.
y Internal events are initiated within the system.
101

Process for Event Identification
y Event identification technique usually completed by
interviewing individuals.
y Through these interviews ,the vents ,and the
processes required to fully respond to them
102

When to use Event Identification
y Event identification technique can be used as initial
approach to any type of process.
y Business area expert find it easy to this approach.
y Top down process decomposition.
Complementary Technique
y Data flow diagram ,Use case analysis ,work flow
modeling are few alternative.
103

Flow chart
Flow charts are visual representation of sequential
flow & control logic.
y Graphically represent the flow of activities.
y Made up of no of graphical symbols.
y A flow chart may be used by Business analyst to
communicate details to developer
104

Process to draw Flow chart
Completion of Flow charts is generally accomplished
by :
y Deciding boundaries of the flow of activities.
y Determining details of activities by using no of
graphical symbols.
y Completing the diagram
105

Flow chart Components
Flow charts is generally accomplished by :
y Activities ,represented by rectangles.
y Flow of activities ,represented by arrow headed
line.
y Start point by rounded rectangle.
y End point by rounded rectangle.
106

Flow Charts can be used for :
y Analyze and describe complex use case.
y Analyze and document business workflows.
y Describe any complex sequence of activities.
y Document activities together.
107

Strengths of Flowchart
y Ability to visually represent complex flows with
multiple decision points.
y Most users find easy to develop & understand.
Weakness of Flowchart
y Does not explicitly support of swim-lanes to
identify responsibility for execution of process.
The DFD conveys similar information to that found in
Activity Diagram ,Work flow diagrams
108

There are number of similar diagrammatic
conventions that found that serve as standard
flowchart these include
y Activity Diagram
y Work flow Diagrams
y The IDEF3 Diagrams
Sequence Diagram
Are used to model the logic of usage scenarios.
109

Key features of Sequence Diagram
y The Sequence Diagram shows particular instances
of each class.
y It shows the stimuli flowing between objects.
y There are two types of objects.
A passive object
Active object
110

Sequence Diagram is most commonly used to
validate the domain model in preparation for
solution design.
y The Sequence Diagrams may be used during
analysis to validate the Class Diagram against Use
Case description.
111

There are number of similar diagrammatic
conventions that found that serve as Sequence
Diagrams
y Activity Diagram
y Work flow Diagrams
y The IDEF3 Diagrams
Sequence Diagrams can be used to model interaction
with the user interface of software system.
.
112

State Machine Diagram
y A number of software intensive systems just like
thermostat.
y A network router runs continuously ,a cell phone
works on demand.
y You model the dynamic aspects of a system by
using state machines
113

Process of State Machine Diagram
y A State machine diagram specifies a sequence of
states that an object goes through its lifetime.
y There may be policy and legal implication to impose
a specific state and transition .
y Emphasis is on tractability from element to
requirement, but also the other related requirement
114

Key features of State Machine Diagram
y A State machine diagram helps detail the life of
object using three main elements.
y The possible sates are depicted by boxes with
round corners
y The transition that show how the object moves
between states is by line with direction arrow.
115

Workflow models
y A workflow model is a visual representation of the
flow of work.
y Workflow model are used to document how work
processes are carried out.
y Workflow model represents :
Business activities
Sequential flow of activities
The person who perform work
116

Process of Workflow models
Completion of a process model where the current &
future states are both modeled generally proceeds
as follows.
y Establish scope of the process.
y Understand the current process, its strength ,
weakness
y Identify opportunities for process improvement.
117

Key features of Workflow models
A workflow model has following components.
y Activities /Tasks
y Sequential flow
y Decision points
y parallel flow
y Swim Lanes
y Terminal
118

Usage considerations of Workflow models
A workflow model can be used by a business analyst
when it is necessary to define how & when the
business process is carried out. This may be to :
y Develop and document an understanding of the
current work flows in business area.
y Identify opportunities for business.
y Understand and communicate complex business
logic.
119

Strengths of Flowchart
y Ability to visually represent complex flows with
multiple decision points and parallel flows.
y Most users find easy to develop & understand.
Weakness of Flowchart
y Multiple sets of diagramming conventions.
y Use cases are sometimes used to document
business process.
120

Prototyping
A prototype is a simplified representation of the user
interface of a proposed software application .
y They allow more visual representation of user
interaction with the system.
y Variants on prototyping includes
Throwaway prototyping
Rapid prototyping
Evolutionary prototyping
121

Process to Make Prototype
The Business Analyst begins by identifying
requirement that will be used to build the
prototype.
y Project team decides what project elements
contribute to risk.
y Align the choice of prototype process with
development lifecycle.
122

Key features of Prototype
There is no formal ,universally accepted standard for
prototype and includes following.
y Shell. This in application that contains the on line
screens.
y The point to provide a visual representation of the
application without complex logic
123

Usage Considerations of Prototype
A prototype is an effective risk reduction technique
when working with unfamiliar business domain.
y A tangible product is very helpful in validating
requirement
y They do not eliminate need to provide a functional
requirement.
124
Story boards/Screen Flows

y
y
y
Story boards/Screen Flows do not involve working

software code.
They do provide early mock up of proposed
business solution functionally.
Variants of Story boards/Screen Flows include :
Paper based prototyping
User experience Story boards
125
Process to create Story boards/Screen Flows

y
The Business analyst begin by identifying ambiguous

project areas that require involvement to clarify
requirements.
The Business analyst also identifies the key end user
types or classes that will utilize the business process
or solution.
Finally ,the Business Analyst will document user
requirements.
126
Key features of Story boards/Screen Flows

y
y
y
There is no formal , universal accepted standard for

Story boards descriptions but must include following
Screen shot
Modeling
127
Usage Considerations- Story boards/Screen

Flows
y
y
y
y
The Business Analyst will develop Story boards to

rapidly develop a description of the user interface
for proposed system.
Story boards/Screen also encourage communication
Story boards/Screen are quick , inexpensive
Story boards may be replaced by a user interface design.
128
Story boards/Screen Flows Examples

y
A way to model the dynamic aspect of a system is

by building Story boards of Scenarios involving
Interaction Diagrams.
Client
Message
Transaction
P:ODBC Proxy
Object
Interaction Diagrams
129

Use Case description y To describe how person or system may interact
with the solution to achieve a goal
y Use Case description are written as a series of
steps performed by actors or by solution that
enable an actor to achieve goal
y No formal standards exists for the use case
description.
130

Process for Use Case description y Inputs for Use Case description include a set of
user profile.
y Once Business Analyst has determined the actor
and the goal that will be satisfied through a
successful execution of the use case ,the basic flow
of use case must be defined .
131

Key Features of Use Case description
y The presentation and structure of a Use Case
Description varies , as there is no universally
accepted standards following are accepted as
common elements of Use Case description
y Name
y Actors
y Preconditions
y Flow of events
y post conditions
132

Usage Considerationsy The Business Analyst should use Goal
Decomposition before developing Use Cases
y Use Cases are good at clarifying scope and providing
high level understanding of user goal.
133

Complementary and Alternative Solution
y Use Cases can be and often are used to describe
Business process flows.
y Use Cases may be replaced by a feature list , user
stories or Textual requirements statement.
134

Use case Diagram
y Use Cases diagrams present a graphical
representation of the problem domain.
y A Use Case diagram is a visual model of actors.
y Standard : The format and elements of Use Case
diagram are defined as part of UML standard.
135

Key Elements of Use case Diagram
y Actor
y Association
y Boundary
136

Use case
y A Use Cases is represented by use case diagrams as
an oval.
y There are two associations that may exist between
Use Cases.
y Extend : allows the insertion of additional behavior
into a use case.
y Include :allows for the base use case to make use of
functionality present in an other use case
137

Process for Use case Diagram
y Business Analysis may begin the development of use
case diagram.
y When the actor is identified ,the analyst must then
indicate which use case must have one & only one
initiating actor.
138

y A use case diagram may be used whether Use
cases are used as a method for documenting
requirements
Complementary and Alternative Techniques
y The Use Case diagram must always be supported by
use case Descriptions or user stories once analysis
is complete
139

Use Case Diagram
Check Balance
Withdraw
Money
Transfer money
Client
140

User Interface Design
y Use interface design focuses on early modeling of
user interaction with specific system elements.
y Standard: There is no formal ,universally accepted
prototyping or user design standard.
141

Process of User Interface Design
y
y
y
The Business Analyst begins by identifying different

user profiles.
They discuss major elements.
Finally ,elicit users opinions on what usability
means to them.
142

Key features of User Interface Designs
User Interface Designs must consider the following
y
y
y
y
User profiles or user classes

Elements for discussion
Organization standards
Modeling standards
143

When to use Interface Design
y The User Interface Designs technique is an effective
method to document requirement for Interface
intensive systems.
y User interface design is good at focusing on system
usage.
144

Complementary and Alternative Solution:
y User interface design may be replaced by
prototyping ,it may be used in conjunction with
storyboard.
y Variations: Variants on user interface design
include:
Dialog maps
Essential user interface design
Essential user interface design style guides
145

User Profiles
y User Profiles descriptions include identifying
,studying ,and modeling current and future intended
end users of business solutions.
y Variations: Variants on user profiles include:
User Task analysis
User profile description
146

Process of User Profiles
y The Business Analyst begins by reviewing the stake
holders analysis completed by project manager.
y Additional review can be provided by subject
matter experts.
y Finally the Analyst will document the result &
incorporate in business requirement document
147

Key features of User Profiles
y There is no universal standards for User Profiles
descriptions , but must include:
User types Each user class is identified
Process of user stories
148

Key features of User Stories
y There is no universal standards for User stories
descriptions , but must include:
Story card :This is written card , possibly index card.
Description: This provides several sentences description
of the problem solved
y
Following attributes included with user story

Unique Identifier
Estimate
Priority
149

User Stories
When to use
y A user story is an effective method to document
requirements for an iterative ,incremental
development methodology.
y User stories create an environment of customer
ownership of features.
150

Complementary and Alternative Solution:
y User stories may be replaced by other development
methodologies.
y Use cases , which describes a listing of the actor
y Feature list
151

Key points
y Requirement analysis and documentation describes
how stakeholders needs are analyzed
y The primary focus of this activity is to develop
analysis models.
y Task defined include :
Structure requirement
Create business domain Model
Analyze user requirement
Analyze Functional requirement
152

Key points
y Analysis Techniques & solution development
methodologies that Business Analyst will use Set of
analysis techniques are :
Business process analysis
Object oriented analysis
Structured analysis
y
The purpose of structuring requirement into

packages is to refine the problem boundary.
y
153

Key points
y Requirement attributes provide information about
the Requirement , such as source of Requirement
y Business Analyst must create a Requirement
document to facilitate a common understanding of
the Requirement.
y Business Rules is usually captured as a textual
statements.
y The purpose of class model is to show entities
relevant to solution.
154

Key points
y Data directory defines the data that is recorded or
used by organization.
y Metadata is information about data used by solution
y A workflow is visual representation.
y Usage model describes the interaction of a user
with the solution.
155
A case on requirement analysis and do a

Mention
A Restaurant in Matunga function as follows
When a customer is entered into restaurant ,the
customer is asked whether he made a reservation
or not .
The people with reservation are seated as quickly as
possible.
Those who do not have reservation are made to
wait in well furnished waiting room.
156

Mention
A Restaurant management has now decided to
provide a technological backbone to the
Restaurant.
Draw Activity diagram for Restaurant.
Draw the class diagram that shows relevant
objects.
Identify use cases for waiter
Design user interface
157

Mention
Solution
y A local area network is set up in Restaurant.
y A wireless network is preferred with waiters
carrying palmtop for booking orders from
customers.
y Order Data entered ,directly goes to kitchen PC
y When order is ready the Chef send message to
waiter
158

Mention
y
y
y
y
y
Access points receives & sends messages from & to

devices.
Following classes are identified for the system
The Manager
Customer
Bill
159

Mention
y
For the waiter use cases are

Take an order
Transmit the order to kitchen
For the Chef use cases are

Store recipe
Retrieve recipe
Notify waiter
160

Mention
Order Entry Screen
Waiter package
Take
Track
O.K
Order
Bill
Message
161

Mention
Bill Entry Screen
Waiter package
Chef
Busser
Send
Read
Order
Bill
Message
162

Mention
When message button is clicked
Waiter package
Total
Print
Order
Bill
Message
163

Mention
Bill Entry Screen
Chef package
Store Rect
Get rect
Acknowledg
e
Time
O.K
Cancel
Notify
164

Mention
When message button is clicked
Waiter package
Acknowledge
Send Message
165
End of Chapter 5
Requirement Analysis &
Documentation
166

Chapter 5 Requirement Analysis

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 5 Requirement Analysis

Uploaded by

Copyright:

Available Formats

Chapter 5

Requirement Analysis &

Requirement Analysis & Documentation

Inputs to Requirement Analysis &

Inputs to Requirement Analysis &

Tasks to be performed For Requirement

Outputs of Requirement Analysis &

Analysis techniques for Requirement

Analysis techniques for Requirement

Business process analysis

Analysis techniques for Requirement

Analysis techniques for Requirement

Structured analysis views primarily a

Task1 Structure Requirements Packages

Predecessors of Task Structure

Process & Elements of Task Structure

Define Solution Boundary

Process & Elements of Task Structure

Process & Elements of Task Structure

Process & Elements of Task Structure

Process & Elements of Task Structure

Task 2 Create Business Domain Model

Process to Create Business Domain Model

Domain and User Variation

Task 3 Analyze User Requirement

Task 4 Analyze Functional Requirement

Process & Elements to Analyze Functional

Process & Elements to Analyze Functional

Process & Elements to Analyze Functional

Process & Elements to Analyze Functional

Process & Elements to Analyze Functional

Process & Elements to Analyze Functional

A model is simplification of reality.

Process & Elements to Analyze Functional

Out of the most commonly used sets of

Process & Elements to Analyze Functional

Process & Elements to Analyze Functional

Process & Elements to Analyze QOS

Process & Elements to Analyze QOS

Process & Elements to Analyze QOS

It provide definitions of common problem

Process & Elements to Analyze QOS

Process & Elements to Analyze QOS

Process & Elements to Analyze QOS

Failure and Disaster Recovery describes how the

Process & Elements to Analyze QOS

Safety requirements specify those requirements

Process & Elements to Analyze QOS

Safety requirements specify those requirements

Process & Elements to Analyze QOS

Training requirements describes the educational

Process & Elements to Determine

Process & Elements to Determine

Process & Elements to Determine

Process & Elements to Determine

Process & Elements to Determine

Process & Elements to verify Requirements

Process & Elements to verify Requirements

Process & Elements to verify Requirements

Data and Behavior models may be referred to as

Process & Elements to verify Requirements

Process & Elements to verify Requirements

Process & Elements to verify Requirements

Decision Tables Example :