Fall 2011
1 / 34

Chapter 6 - PowerPoint PPT Presentation

  • Uploaded on

Fall 2011. Chapter 6. Requirements Engineering. Preparation for Requirements Engineering. Obtain and Organize the Agreed upon Resources and Process. Plan For Requirements Activities. Agreeing on Resources, Process and Schedule for Requirements Activities.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Chapter 6' - jessamine-french

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Fall 2011

Chapter 6

Requirements Engineering

Preparation for requirements engineering
Preparation for Requirements Engineering

Obtain and

Organize the

Agreed upon

Resources and






Agreeing on


Process and

Schedule for



1. Prior to actually performing the requirements engineering activities,

it is important to plan for the resources and time needed to perform

this crucial step in software engineering.

2. Some organizations even perform requirements engineering as a separate ,

stand-alone activity and price it separately, with the option of folding the cost

Into the whole project if they get the call to complete the software project.

Major requirements engineering activities
Major Requirements Engineering Activities

  • Elicitation

  • Documentation and definitions

  • Specifications

  • Prototyping

  • Analysis

  • Review and Validations

  • Agreement and acceptance

Requirements engineering activities
Requirements Engineering Activities












Agreement &




Why is this set of activities important and why should requirements be documented
Why is this set of activities important and why should requirements be documented?

  • Clear requirements are needed for design and implementation activities.

  • Requirements documentation is needed to create test cases and test scenarios - - - especially for large systems where the test team is a separate group of people from the developers.

  • Requirements document is needed to control potential scope-creep.

  • Requirements document is needed to create user training material, marketing material, and documents for support and maintenance.

  • Requirements document provides a way to segment a large project, prioritize releases , and easier project management

Think about agile processes where this crucial step may sometimes be

compromised by the novice software engineers.

Requirements elicitation
Requirements Elicitation requirements be documented?

  • Requirements may:

    • Be given to the software engineers

      • Second or third follow-on release of a “planned” sequences of software product where requirements are already established

      • Requirements provided as a part of a request for price quotation for a software development project

    • Have to be established by software engineers

      • Users have an understanding of only the requirements related to their specific job tasks

      • The business rationale and goals are not clear

      • There may be contradicting and incomplete requirements stated by the users and customers

High level requirements elicitation
High Level Requirements Elicitation requirements be documented?

  • Need to seek out the business and management perceptions and goals for the software project

    • Business opportunity and business needs

    • Justification for the project

    • Scope

    • Major constraints

    • Major functionality

    • Success Factor

    • User characteristics

6 dimensions of detailed requirements elicitation
6-Dimensions of Detailed Requirements Elicitation requirements be documented?

Business Workflow

Individual Functionality

Data and Data formats


Existing & Systems Interfaces

Other Constraints: Performance,

Reliability, etc.

User Interfaces

Requirements analysis
Requirements Analysis requirements be documented?

  • Requirements analysis is composed of:

    • Categorizing the requirements

    • Prioritizing the requirements

Requirements categorization
Requirements Categorization requirements be documented?

  • By detailed requirements area:

    • Individual functionality

    • Business flow

    • Data and information needs

    • User interfaces

    • Other interfaces to external systems

    • Various constraints

      • Performance

      • Security

      • Reliability

      • Etc.

Requirements categorization cont
Requirements Categorization (cont.) requirements be documented?

  • Using OO’s Use Case, which identifies:

    • Basic functionality

    • Pre-conditions of functionality

    • Flow of events or scenarios

    • Post-conditions for the functionality

    • Error conditions and alternative flows

  • Using OO Use Case methodology which identifies:

    • Actors (or all external interfaces with the system, including the users)

    • Related use cases

    • Boundary conditions

Requirements categorization cont1
Requirements Categorization (cont.) requirements be documented?

  • View Oriented Requirements Definition (VORD) is based on the concept that requirements are viewed differently by different people:

    • Identify stakeholders and their viewpoints of the requirements

    • Categorize the viewpoints of requirements and eliminating any duplication

    • Refine the identified viewpoints of requirements

    • Map the viewpoints of requirements to the system and the services that the system must provide

Requirements prioritization
Requirements Prioritization requirements be documented?

  • Most of the time we have limitations of :

    • Time

    • Resources

    • Technical capabilities

  • We need to prioritize the requirements to satisfy these limitations

Requirements priorities
Requirements Priorities requirements be documented?

  • Criteria for prioritization:

    • Current user/customer demands or needs

    • Competition and current market condition

    • Anticipated future and new customer needs

    • Sales advantages

    • Critical problems in existing product

  • These are often subjective and requirements should be prioritized with the help of many of the stakeholders.

A simple requirements prioritization list
A Simple Requirements Prioritization List requirements be documented?

Brief Req.


Req. source

Req. priority

Req. Status

Req. #

One page

query must

respond in

less than

1 second

A Major




Priority 1*

Accepted for

this release

# 1

Help text

must be

field sensitive

Large account


Priority 2


For next


# 2

* Priority may be 1, 2, 3, or 4, with 1 being the highest

Requirements comparison and prioritization
Requirements Comparison and Prioritization requirements be documented?

  • Requirements prioritization is an activity of comparing the requirements and placing them in some order relative to each other.

    • Done with just experience and gut feel

    • Done with a little more rigor:

      • Sort by priority groups (e.g. previous 2 charts) where the priority groups are based on some prioritization criteria list

      • Pair-wise comparison, normalize and compute relative value using the Analytical Hierarchical Process (AHP) – see pages 159-161 of text book

Pairwise comparison matrix
Pairwise Comparison Matrix requirements be documented?

Sum each column and divide each value in the column by the sum

Pairwise comparison matrix1
Pairwise requirements be documented? Comparison Matrix

  • Sum each row:

    • Row 1 (Req1) = 1.92

    • Row 2 (Req2) = .47

    • Row 3 (Req)3 = .61

  • Divide each sum by the number of requirements:

    • 1.92/3 = .64

    • 0.47/3 = .15

    • 0.61/3 = .20

  • Results

    • Req1 highest (64% of total req value)

    • Req3 second highet (20%)

    • Req2 lowest (15%)

Only good for small number of requirements

Requirements definition prototyping review
Requirements Definition/Prototyping/Review requirements be documented?

  • Once the requirements are solicited, analyzed and prioritized, more details must be spelled out. Three major activities which may be intertwined must be performed:

    • Requirements definition

    • Requirements prototyping

    • Requirements reviewing

Requirements definitions
Requirements Definitions requirements be documented?

  • Requirements definitions may be written in different forms:

    • Simple Input/process/output descriptions in English

    • Dataflow diagrams (DFD)

    • Entity Relations diagram (ERD)

    • Use Case Diagram from Unified Modeling Language (UML)

  • Once the requirements are defined in detail using any of the above forms, they still need to be reviewed by the users/customers and other stakeholders.

Requirement definition using english and input process output diagram form
Requirement Definition using English and requirements be documented?Input-Process-Output Diagram Form

Req. #




- Items by type

and quantity

- Submit request

- Accept the

items and



- Display


message and

- Ask for



# 12: customer


Requirements definition using dfd
Requirements Definition using DFD requirements be documented?

Inventory Info.

Package Data







Order Processing





Customer credit,

address, etc.

Customer Info DB

Requirements definition using entity relation diagram erd
Requirements Definition using requirements be documented?Entity- Relation-Diagram (ERD)






Cardinality: specifies the number of occurrences of entities



Modality: specifies the necessities of relationship to exist

Requirements definition specifying entity and attributes
Requirements Definition specifying requirements be documented? Entity and Attributes

(a) Graphical form

(a) Tabular form



- Name

- Age




- Address

- Street

- City

- State

- Zip





Add Course requirements be documented?

Register For Section

Add Section


Add Student

Choose Section


Requirements Definition using Use Case Diagram

Requirements prototyping
Requirements Prototyping requirements be documented?

  • Requirements prototyping mostly address the User Interface (UI) part of the requirement in terms of:

    • Visual looks (size, shape, position, color)

    • Flow (control and logical flow)

  • The prototyping may be performed in one of the two modes:

    • Low fidelity : using paper/cardboard to represent screens and human to move the boards

    • High fidelity : using automated tools such as Visual Basic to code the screens and direct the logical flow of these screens

Requirements specification
Requirements Specification requirements be documented?

  • Once the requirements are defined, prototyped and reviewed, it must be placed into a Requirements Specification document

  • IEEE /EIA Standard 12207.1-1997 may be purchased from IEEE. It outlines the guideline for 3 major sections of a requirements specification document.

    • Introduction

    • High Level description

    • Detailed descriptions

      • Details of each functionality (input-out-process)

      • Interfaces, including user interfaces and network interfaces

      • Performance requirements (response time, throughput, etc.)

      • Design constraints, standards, etc.

      • Additional attributes such as security, reliability, etc.

      • Any additional unique requirements

Software requirements specification
Software Requirements Specification requirements be documented?

  • The Software Requirements Specification (SRS) specifies the requirements for a Computer Software Configuration Item (CSCI) and the methods to be used to ensure that each requirement has been met. Requirements pertinent to the CSCIs external interfaces may be presented in the SRS or in one or more interface requirements specifications (IRSs).

  • 1.0 Introduction to the Document

    • 1.1 Purpose of the Project

  • State the purpose of the system or subsystem to which this document applies.

    • 1.2 Scope of the Project

    • 1.3 Acronyms, Abbreviations, Definitions

    • 1.4 References

    • 1.5 Outline of Rest of SRS

  • 2.0 General Description of Product

    • 2.1 Context of Product

    • 2.2 Product Functions

    • 2.3 User Characteristics

    • 2.4 Constraints

    • 2.5 Assumptions and Dependencies

Software requirements specification1
Software Requirements Specification requirements be documented?

  • 3.0 Specific Requirements

    • 3.1 External Interface Requirements

      • 3.1.1 User Interfaces

      • 3.1.2 Hardware Interfaces

      • 3.1.3 Software Interfaces

      • 3.1.4Communications Interfaces

    • 3.2 Functional Requirements

      • 3.2.1 Class 1

        • Short, imperative sentence stating highest ranked functional requirement.

        • DescriptionA full description of the requirement.

        • CriticalityDescribes how essential this requirement is to the overall system.

        • Technical issuesDescribes any design or implementation issues involved in satisfying this requirement.

        • Cost and scheduleDescribes the relative or absolute costs associated with this issue.

Software requirements specification2
Software Requirements Specification requirements be documented?

  • RisksDescribes the circumstances under which this requirement might not able to be satisfied, and what actions can be taken to reduce the probability of this occurrence.

  • Dependencies with other requirementsDescribes interactions with other requirements.

  • ... others as appropriate

  • 3.2.2 Class 2

  • 3.2.3 Class 3

  • . . .

    • 3.3 Performance Requirements

    • 3.4 Design Constraints

    • 3.5 Quality Requirements

    • 3.6 Safety requirements

    • 3.7 Security and Safety Requirements

    • 3.8 Computer Resource Requirements

    • 3,9 Personnel Requirements

    • 3,10 Training Related Requirements

    • 3.11 Logistics Related Requirements

    • 3.12 Other Requirements

  • Software requirements specification3
    Software Requirements Specification requirements be documented?

    • 4.0 Notes

      • 4.1 Intended Use

      • 4.2 Definitions Used in this Document

      • 4,3 Abbreviations Used in this Document

      • 4.4 Changes from Previous Issue

    • 5.0 Appendices

    Requirements sign off
    Requirements “Sign Off” requirements be documented?

    • Having a requirements specification agreed to and signed off is important:

      • Serves as a milestone marker and formally exits a phase of software engineering

      • Serves as baseline from which any future changes can be monitored and controlled

    Requirements traceability
    Requirements Traceability requirements be documented?

    • Capability to trace a requirements is needed to ensure that the product has fully implemented the requirements.

    • We need to trace requirements:

      • Requirements from source (people and documents)

      • Requirements to later steps (design, implementation)

    • We also need to link requirements to other “pre-requisite” requirements.

    Partially filled traceability table
    Partially filled Traceability Table requirements be documented?