Requirements

1
Requirements

• Lecture5/Spring 2000
• CSEE/West Virginia University
• Ramana Reddy

2
Why do we need Requirements?

• What to build?
• A contract between client and developer
• A detailed goal statement
• Scope delimitation/Cost Est.
• Discover other ways to meet the need
• Build vs Buy

3
Who is involved?

• Client - A CIO (and consultants)
• Developer - Internal/External
• User

4
Requirements -gt Specifications

• What will it do?
• How much will it cost?
• When will it be deployed?
• What will be the impact?

5
Focus on What, not How

• Is this a replacement?
• Is this an extension?
• Modernization
• Technology insertion (e.g. Web based!)
• Meeting regulations
• Adopting standards
• Closed -gt Open

6
Barking-up the Wrong Tree!

• Focus on wrong part of the org.
• Perceived /Real Need

7
Aspects to be considered

• Impact on process
• Acceptance
• Expectations
• Transition to new system
• Fall-Back mechanisms
• Coping with rapid change in organizations and
  technology

8
Aspects of Requirements

• Functional
• Case/Response
• Unexpected event handling
• Performance (e.g. response time)
• Environment (platform etc.)
• Dealing with Legacy

9
Aspects of Requirements (contd.)

• Scale (e.g. how many transactions?)
• Cost/Schedule
• Support structure
• Reliability
• Maintainability
• Perspicuity

10
Requirements Should be

• Simple
• Abstract
• Concise
• Unambiguous
• Complete
• Consistent

11
Requirements Should be (Contd.)

• Detailed
• Testable
• Incrementally realizable
• Understandable
• Modifiable
• Traceable
• Realizable
• Proportional to the real need

12
Problems/Challenges

• Customers are not sure what they want
• Requirements creep
• Communication gap
• Domain specific language
• Users are not always involved
• Asking for too much
• Going with fads

13
Requirements Process

• Interviews
• Questionnaires
• Storyboarding
• Rapid Prototyping/Mockup
• Dataflow

14
Requirements Process (Contd.)

• Process modeling
• Simulation
• Refinement
• Validation
• Spec document

15
DATA FLOW DIAGRAM (from Prof. Rugabar)
Customer Requirements
(Validation and selection of modeling technique
ignored)
Problem Model
Model Problem
Interview Customer
Prepare Functional Spec
Interview Notes
Organize Requirements List
Verified Requirements
Functional Specification
Problems with Requirements
Analyze Requirements
Listed Requirements
16
Contents of Req. Doc

• Description
• Functionality
• Dataflow
• Environment
• Operational Requirements/Performance

17
Contents of Req. Doc (Contd.)

• System model
• File description
• User interface
• Standards
• External interfaces
• e.g. a vendor supplied service

18
Next few slides from Rugabar
19
TYPES OF MODELS

• Data Models - ER, object-oriented
• State machines / State charts
• Data Flow Diagrams
• Formal models
• ...

20
REQUIREMENTS VERIFICATION

• Completeness - missing pieces
• Consistency - absence of conflicts
• Clarity - absence of ambiguity
• Coherence - singleness of purpose
• Feasibility - capable of being accomplished
• Testability
• (Traceability) - throughout the life cycle

21
NON-FUNCTIONAL REQUIREMENTS

• Performance - efficiency, response time, load
• Resource utilization - memory, disk, ...
• Accuracy - for numerical calculations
• Development approach - methodology, language
• Environment - hardware, operating system
• Documentation
• Configurations - options, subsets, binary /
  source
• Installation
• Cost and schedule
• Acceptance Criteria

22
ILITIES

• Integrity - loss of information
• Security - controlled access to information
• Reliability / Availability - mean time to
  failure mean time to repair
• Portability - to other operating systems,
  programming languages, libraries, hardware
• Maintainability
• Reusability

23
SPECIFICATIONS

• Aimed at developers
• May be included in or separated from the
  requirements document
• What, not How
• Functional - formal / informal
• Non-functional constraints

24
USES OF A SOFTWARE SPECIFICATION

• Design and development of software
• User's manual
• Acceptance test plan

25
ANALYSIS TECHNIQUES

• Context diagrams
• Goal hierarchies
• Use cases/scenarios
• Formal modeling
• Simulation
• Object-oriented analysis

26
CONTEXT DIAGRAMS

• Top level dataflow diagram
• Separates what is inside the system from what is
  outside
• Rectangles for external participants/actors
• Parallel horizontal lines for data repositories
• A single oval/circle for the system
• Arcs indicating flows of data

27
GOAL HIERARCHY

• Nodes denote customer goals (achievement,
  maintenance, defensive)
• Levels indicate the goal/subgoal hierarchy
• Arc types indicate ordering constraints
• Sequential (this goal must be accomplished before
  this goal)
• Interleaved/parallel - may be achieved
  concurrently
• Alternative (successful completion of any of the
  subgoals satisfies the parent goal)