Requirements Analysis

1
Requirements Analysis
2
Goals of Requirements Analysis

• Create requirements containing sufficient detail
  and of high enough quality to allow realistic
  project planning as well as successful design and
  implementation.
• Scrutinize requirements for errors, conflicts,
  omissions and boundaries.

3
Requirements Analysis Practices

• Analyze feasibility
• Allocate requirements to subsystems
• Create prototypes where necessary
• Model the requirements
• Prioritize the requirements
• Define system boundaries and interfaces
• Create consistent data definitions

4
Requirements Analysis Checklist

• Premature Design Does the requirement include
  premature design or implementation information?
• Combined Requirements Does the description of a
  requirement describe a single requirement or
  could it be broken down into several different
  requirements?
• Unnecessary Requirements Is the requirement
  gold plating? That is, is the requirement a
  cosmetic addition to the system which is not
  really necessary.
• Use of Non-standard Components Does the
  requirement mean that non-standard hardware or
  software must be used?

5
Requirements Analysis Checklist contd

• Conformance with Business Goals Is the
  requirement consistent with the business goals
  defined in the introduction to the requirements
  document/
• Requirements Ambiguity Is the requirement
  ambiguous i.e. could it be read in different ways
  by different people?
• Requirements Realism Is the requirement
  realistic given the technology which will be used
  to implement the system?
• Requirements Testability Is the requirement
  testable? Is it stated in such a way that a test
  can be derived to show if the system meets the
  requirement?

6
Requirements Analysis Artifacts

• System Boundaries Context Diagram
• Requirements Modeling Class Diagrams, Activity
  State Diagrams, Interaction Diagrams, Sequence
  Diagrams, Data Flow Diagrams, Entity-Relationship
  Diagrams
• Data Definition Data Dictionary
• Requirements Priority Prioritization Matrix
• Requirements Definition, Risk Mitigation,
  Feasibility Prototypes

7
Context Diagram - Purpose

• Highlights the boundary between the system and
  the outside world.
• Highlights the people, organizations, and outside
  systems that interact with the system under
  development.
• Special case of the data flow diagram.

8
Context Diagram - Notation
Process - Represents the proposed system
Terminator - Represents the external entities
Flow - Represents the in and out data flows
9
Context Diagram - Example
Customer Service
Application
Customer
Credit
Bills
Collection Company
Payment
Overdue Accounts
Credit Card Processing
Corporate Accounting System
Account Summary
Transaction
Payment
Store
10
Use-Case Analysis

• Use-case analysis is where the requirements meet
  object-orientation
• Recall in the Unified Process, the use-case
  model is the primary artifact in the requirements
  model
• In use-case analysis, identify the classes which
  perform a use-case flow of events
• Distribute the use-case behavior to those classes
• Identifying the responsibility of the classes
• Develop use case realizations that model the
  collaborations between instances of the
  identified classes
• How the class instances work together to deliver
  the requirements
• The result is a first-draft, rough-cut of the
  system object model
• An abstraction of the design model refined
  during design

11
Use-Case Analysis - Steps

• Supplement the Use-Case Description
• For each use-case realization
• Find classes from use-case behavior
• Distribute use-case behavior to classes
• For each resulting analysis class
• Describe responsibilities
• Describe attributes and associations
• Qualify architectural analysis mechanisms
• Unify analysis classes
• Checkpoints

12
Analysis Classes A First Step Towards Executables
Use-Cases
Analysis Classes
Design Elements
Source Code
Executables
Use-Case Analysis
13
Data Flow Diagram - Purpose

• Provides a means for functional decomposition.
• Primary tool in analysis to model data
  transformation in the system.

14
Data Flow Diagram - Notation
Represents functions in the system (transforms
Inputs into Outputs)
Represents the external entities that the System
communicates with
Represents data flows
Represents data stores (a collection of data at
rest)
15
DFD Example from Text
16
Data Dictionary

• A repository that defines the data elements or
  attributes used in the system
• It is not the project glossary
• Makes it easy to find info about the data
• Avoids redundancy and maintenance issues, over
  being in various func. req.
• Have it as an appendix in your SRS (project)

17
DD Notation

• Primary data element
• Where an element does not need or require further
  decomposition
• Defined with a comment text
• Data type, size, range of values etc. are
  presented.
• Composition
• Used to show multiple data items
• Optional items are enclosed in ()
• Iteration minmax item
• Used to show that mult instances of an item can
  appear
• Selection item item
• When a data element can be of a set of discrete
  values

18
DD Examples

• Customer Name
• Phone Number

19
DD Notation

• Entry comprised of (and listed in alphabetical
  order)
• Name its name
• Aliases if it goes by another name as well
• Used in the use cases it is present in, by id
  and name
• Description the notation goes here
• Notes any special notes about it

20
Entity Relationship Diagram (ERD) - Purpose

• A graphical representation of the data layout of
  a system at a high level of abstraction.
• Defines data elements and their
  inter-relationships in the system.

21
Entity Relationship Diagram - Text Example