Requirements Engineering

1
Requirements Engineering

• CS3911
• Spring 2005

2
Agenda

• Deliverables
• Today 5 PM - Status Report 1
• Project Selection
• Team Formation
• Email addresses
• Project Manager
• Wednesdays class
• Lecture Requirements
• Final Team Formation

3
Requirements Engineering

• Elicitation (Sources and Techniques)
• Analysis (Conflict Handling, Bounds, Scoping,
  Elaboration)
• Specification (SRD, SRS)
• Validation (Reviews, Prototyping, Model Checking)
• Management (Traceability, Change Management)

4
Introduction to Requirements

• Definition

A feature of the system or a description of
something the system is capable of doing in order
to fulfill the systems purpose

• Types of Requirements
• Functional
• Non-functional, Non-behavioral, Quality Attributes

• Strengths
• Shall (Must)
• Should (Desired)
• Will (Fact)
• May (Preferred)

5
Requirements Phase

• Goal
• To understand the problem
• Necessary to Understand Requirements
• Organization (Politics/Overt-Covert)
• Existing Systems (HW/SW)
• Processes (Formal and Informal)
• Improvements
• Where does this information come from?
• How do we get it?

6
Requirements Elicitation

• Techniques
• Interview / Meeting
• Survey / Questionnaire
• Observation
• Ethnography / Temporary Assignment
• Business Plans
• Review Internal / External Documents
• Review Existing Software / System
• Domain Analysis
• Prototypes

7
Requirements Elicitation Caveat

• Dont piecemeal the customer to death.
• Have an elicitation plan and follow it.
• Analyze what you have and then plan to fill in
  the gaps.
• Your customers time is precious.
• DO NOT tell themgive us your requirements by
  Friday so we can write our document.

8
Who do we talk to?

• Customer (economic buyer)
• User
• Stakeholder (anyone materially affected by
  system)
• Actors (someone or something outside the system
  that interacts with the system)
• Other systems
• Regulators

Driven by kind of system (shrink wrap, vertical,
custom)
9
Requirements Analysis

• Goal
• To bridge the gap between the problem domain and
  the technical domain
• Tasks
• Problem Recognition
• Evaluation and synthesis
• Modeling (Static/Dynamic/User)
• Specification
• Review

10
Requirements Review

• Correctness
• Accurately reflects needs
• Completeness
• No 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
• What not how
• Modularity / organized
• Needed by the customer

11
Common Problems

• Forward reference
• Mention of a feature before it is defined
• Noise
• Text that contains no relevant information
  redundancy, remorse
• Wishful thinking
• A requirement that cannot be validated

12
Requirements Specification

• Goal
• To provide a representation of the software for
  the customers review and approval
• Basis for Design and Acceptance Test
• Developed as a joint effort between the developer
  and the customer
• Serve as basis for review for both customer and
  developer
• Culmination of requirements analysis
• Tries to focus on What not How

13
Requirements Characteristics

• Requirements should be simple not compound
• Requirements should be testable
• Else they are objectives
• Requirements should be organized
• Related requirements grouped
• Abstract requirements containing detailed
  requirements
• Priorities indicated
• Requirements should be numbered
• So that they can be traced
• Descriptive (what) not prescriptive (how)

14
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

15
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

16
Software Requirements Specification (SRS)

• Includes Requirements Definition Specification
• Principles Heninger 80
• Should specify external system behavior
• Should specify implementation constraints
• Should by easy to change
• Should serve as reference tool for maintenance
• Should record forethought about system lifecycle
• Should characterize acceptable responses to
  undesired events

17
Some Samples

• As Written Software will not be loaded from
  unknown sources onto the system without first
  having the software tested and approved.
• Better 3.2.5.2 Software shall be loaded onto
  the operational system only after it has been
  tested and approved.
• Better 3.2.5.2 Software shall be loaded onto the
  operational system only after it has been tested
  IAW MIL-SPEC 3425 and approved by the CCB.

18
Another Sample

• 3.4.6.3 The system shall prevent the processing
  of duplicate electronic files by checking a new
  SDATE record. An email message shall be sent.
• 3.4.6.3 The system shall
• a. Prevent processing of duplicate electronic
  files by checking the date and time of
  submission.
• b. Send the following email message
• Request updated submission of date and time, if
  necessary, or
• That the processing was successful when
  successful.

19
From Student SRS

• 3.1.1.1 The data filter shall contain text boxes
  into which the user may type the exact value to
  filter.
• 3.1.1.1 The system shall allow the user to enter
  a text string for use in filtering the results of
  a data search.

20
From Student SRS

• The system shall allow the user to enter
  information such as name and address.
• 3.7.1 The system shall allow the user to enter
  the following information items name, address,
  phone.

21
One last sample

• 3.2.8.6 When doing calculations, the software
  shall produce correct results.
• No, You think????? Delete on sight.

22
Software Requirements Specification (SRS)
Lets go over the sample template from the
webpage.