Purpose of Requirements Analysis

1
Purpose of Requirements Analysis

• Process of discover, refinement, modeling, and
  specification
• o Bridge gap between system level SW
  allocation and
• design
• o Enable system engineer to specify
  software function
• and performance
• o Indicate SW interface with other system
  elements
• o Establish design constraints
• o Analyst must
• - Refine SW allocation and
• - build models of the process, data,
  and behavioral
• domains
• o RA provides SW designer with
  representation of info
• and function
• can be translated into data, architectural,
  and proce-
• dural design.
• o Allow developer and customer to assess
  quality

2
Analysis Tasks

• o Problem Recognition
• o Evaluation and synthesis
• o Modeling
• o Specification,
• o Review

3
Role of Analyst

• o Evaluate flow and content of information
• o Define and elaborate all SW functions
• o Understand SW behavior in context of events
  affecting
• system
• o Establish system interface characteristics
• o Uncover design constraints
• o Remember, assessing the WHAT!
• - What data?
• - What functions must system perform?
• - What interfaces?
• - What constraints apply?

4
Problem Areas

• o Communication Skills (different levels)
• - High-level interaction
• - More detail extraction from customer
• - Tailor communication approach towards
  customer
• o Facilitated Application Specification
  Techniques (FAST)
• Joint team of customer with developers
  (marketing, an-
• alysts, programmers, HW engrs)

5
Analysis Principles

• o Information domain of problem must be
  represented
• and understood.
• o Develop models that illustrate system
  info, function,
• and behavior
• o Models and problem should be decomposed into
  hier-
• archical organization
• o Process progress from essential (high-level
  requirements)
• to implementation details

6
Information Domain

• o All SW applications can be called data
  processing.
• Software is built to process data
• o SW also processes events
• o data and control (events) both reside within
  the Info
• Domain
• o 3 views of data and control as processed by
  computer
• programs
• 1. Information_Flow______how data and
  control change as
• they move through system
• 2. Information_content______represents
  individual data and
• control items making larger items
  of information
• (components wrt to data and events)
• 3. Information_structure______Internal
  organization of data
• control items (e.g. table, tree)

7
Modeling and Specification

• o Modeling____
• - Aid in understanding information,
  function, and be-
• havior of system.
• - Focal point for review (determine
  completeness, con-
• sistency, and accuracy of specification)
• - Foundation for design ("mapping" from
  presenta-
• tion to implementation context.
• o Partitioning/Decomposition_________
• - Decompose large/complex problem into
  easily un-
• derstandable parts
• - Establish interfaces between parts to
  achieve overall
• functionality.
• - Strive for hierarchical representation
• (partition uppermost element according
  to the fol-
• lowing)
• O Increase detail by moving vertically
• O Increase breadth or functionality by
  moving hor-
• izontally.

8
Essential and Implementation Views

• o Essential_View____
• of SW requirements
• - Presents functions to be accomplished
• - Information to be processed
• - Without regard to implementation details
• o Implementation_View________
• of SW requirements
• - Presents "real-world" implementation
  perspective
• of processing functions and information
  data struc-
• tures
• - May be physical representation
  (depending on the
• objective)

9
Prototyping

• o Prototype is mostly for customer assessment
• o Several_steps_of_prototyping_______
• 1. Evaluate SW request and determine if
  feasible.
• 2. Develop abbreviated representation of
  requirements
• 3. Develop abbreviated design
  specification from re-
• quirements
• 4. Prototype SW is created, tested, and
  refined
• paper prototype through pictorial
  representations
• 5. Present prototype to customer
  obtain feedback,
• then refine
• o Prototyping_Methods_and_Tools___________
• - Fourth-generation techniques (database
  and report
• languages)
• - Reusable SW components
• - Formal Specification and Prototyping
  environments
• O Executable spec languages
• O Translate specs into exec. code

10
Specification

• Formal spec languages lead to formal
  representation of
• requirements that may be verified or further
  analyzed
• Specification_Principles_____
• o Cognitive model (take user's perspective)
• o Operational (be able to verify)
• o Tolerant of incompleteness and
  modifiable (abstract,
• may need refinement)
• o Localized and loosely coupled

11

12
Representation Guidelines

• o Representation format and content should be
  relevant
• to problem
• o Information contained within
  specification should be
• nested
• o Limited number of and consistent use of
  diagrams and
• other notational forms
• o Revisable representation (CASE tools)

13

14
Software Requirements Specification

• o Function and performance allocated to SW
  from sys-
• tem engineering should be refined by
• - establishing complete information
  description
• - detailed functional description
• - performance requirements and design
  constraints
• - validation criteria
• o Standard formats (example IEEE no.
  830-1984)

15
Specification Contents

• - Introduction states goals and objectives
  of SW
• describe context of computer-based
  system
• - Information Description gives
  detailed descrip-
• tion of problem
• O Information flow and structure
  documented
• O HW, SW, and human interfaces
  described for ex-
• ternal system elements and internal
  SW functions
• - Functional Description description of
  each func-
• tion needed to solve the problem
• O Processing narrative for each
  function
• O Design constraints state and
  justify
• O Give performance characteristics
• O One or more graphical diagrams
  represent overall
• structure and interaction between SW
  functions
• and other system elements

16
Specification Contents

• - Behavioral Description examines operation of
  SW
• as consequence of
• O external events and
• O internally generated control
  characteristics
• - Validation Criteria (very important)
• O "How do we know if SW is successful
  implemen-
• tation?"
• O "What classes of tests are necessary
  to validate
• function, performance, and
  constraints?"
• - Bibliography contains references to all
  documents
• that relate to software
• O SE documentation (e.g., Handbook)
• O Technical references (e.g., Algorithm
  texts, Pro-
• gramming Language texts, Manuals)
• O Vendor Literature (e.g., Sun
  OpenWindows)
• O Standards (IEEE requirements
  standards)