Scribd
Upload
575 views

Requirements Analysis & Requirements Specification

This document provides an overview of requirements engineering and defines key terms related to requirements analysis and specification. It discusses the process of requirements elicitation, analysis, specification, and management. It describes how requirements are analyzed to understand customer and stakeholder needs and documented clearly in a requirements specification. Functional, performance, interface, and quality requirements are types that may be specified. The document emphasizes distinguishing requirements from design and clarifying what versus how.

Uploaded by

Rohini Rowx
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
575 views

Requirements Analysis & Requirements Specification

This document provides an overview of requirements engineering and defines key terms related to requirements analysis and specification. It discusses the process of requirements elicitation, analysis, specification, and management. It describes how requirements are analyzed to understand customer and stakeholder needs and documented clearly in a requirements specification. Functional, performance, interface, and quality requirements are types that may be specified. The document emphasizes distinguishing requirements from design and clarifying what versus how.

Uploaded by

Rohini Rowx
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 28

Requirements Analysis & Requirements Specification

Originally developed by Michael Madigan StorageTek Manager, PAL Engineering

Software Engineering of Standalone Programs University of Colorado, Boulder

Requirements Engineering

Requirements Engineering

Requirements Elicitation

Requirements Analysis Requirements Verification

Requirements Specification Requirements Management

Requirements Analysis & Specification Definitions


Requirements

The process of studying and analyzing the customer and the


user/stakeholder needs to arrive at a definition of software requirements.1

Analysis

Requirements

A document that clearly and precisely* describes, each of the


essential requirements of the software and the external interfaces.
(functions, performance, design constraint, and quality attributes)

Specification

Each requirement is defined in such a way that its achievement

is capable of being objectively verified by a prescribed method; for example inspection, demonstration, analysis, or test.2

Types of Requirements
Functional

requirements Performance requirements Speed, accuracy, frequency, throughput External interface requirements Design constraints Requirements are usually about what, this is a
Quality

how.

i.e. reliability, portability, maintainability,


supportability

attributes

What vs. How Dilemma3


User Needs What How System Requirements System Design Software Requirements Software Design What How What How What How

Requirements vs. Design


Requirements Describe what will be delivered3 Primary goal of analysis: UNDERSTANDING3 There is more than one solution Customer interested Design Describe how it will be done3 Primary goal of design: OPTIMIZATION3 There is only one (final) solution Customer not interested (Most of the time) except for external

Software Quality Attributes4


Correctness Reliability

Rating = 1 (Num Errors/ Num LOC) Can be allocated to subsystems Efficiency Integrity Usability Survivability Maintainability Verifiability Flexibility Portability Reusability Interoperability Expandability

Analysis of Elicitation results helps to create a Vision


Settle on which problem - Explain in the problem statement (2.2) Marketing group establishes positioning of the product (2.3) Stakeholder and User Summaries - User is a special case of stakeholder - Identify all stakeholders w.r.t. development: Name Represents Role - Identify all users w.r.t. system: Name Description Stakeholder

Stakeholder Profiles (3.5)


Representative - who (name) is representing this stakeholder type. Description - brief description of the stakeholder type Type - Qualify s-hs expertise, technical background, degree of sophistication Responsibilities - List s-hs key responsibilities with regard to the system being developed - why a stakeholder? Success Criteria - How does the stakeholder define success? How rewarded? Involvement - involved in the project in what way? Requirements reviewer, system tester, ... Deliverables* - required by the stakeholder Comments/Issues - Problems that interfere w/ success, etc.

User Profiles (3.6)


Representative - Who represents this user? (might be a stakeholder) Description - of the user type Type - qualify expertise, technical background, degree of sophistication Responsibilities - users key resp.s w.r.t. system being developed Success Criteria - how this user defines success? rewarded? Involvement - How user involved in this project? what role? Deliverables - Are there any deliverables the user produces? For whom? Comments/Issues - Problems that interfere w/ success, etc. This includes trends that make the users job easier or harder

User Environment (3.4) -- working environment of target user


Number of people involved in doing this now? Changing? How long is a task cycle now? Changing? Any unique environmental constraints: mobile, outdoors, inflight, etc. Which system platforms are in use today? future? What other applications are in use? Need to integrate?

Key Stakeholder or User Needs (3.7)


List key problems with existing solutions as perceived by the stakeholder or user. What are the reasons for this problem? How is it solved now? What solutions does the stakeholder want? What is relative importance of solving each problem?

Alternatives and Competition (3.8)

Product Overview (4.) (at last!)


4.1 Product perspective (context) Put the product in perspective to other related products and the users environment. Independent? Component of a larger system? How do the subsystems interact with this? Known interfaces between them and this component? Block diagram

Product Overview (4.) (at last!)


4.2 Summary of Capabilities Customer Benefit 1. 2. 3. 4.
Supporting Features

Product Overview (4.) (at last!)


4.3 Assumptions and dependencies What factors affect the features above? List assumptions that, if changed, ALTER this document
4.4 Cost and pricing -- not done by engineering 4.5 Licensing and installation -- different types of license enforcement will create more requirements for the development effort

Product Features (5.)


Whats a feature? - high level capability necessary to deliver benefit to the user - externally desired service that typically requires inputs to achieve Level of detail must be general -- this is not the requirements spec for the developers. Provide the basis for product definition, scope management, and project management. Each will be expanded in the use-cases or other requirements Externally perceivable by users or external systems

What is not in the Product Features Section?


Design
Constraints

Design constraints External constraints Quality Ranges -- These go in section 7 ranges for performance, robustness, fault tolerance, etc. that
are not really features (specific capabilities, functions)

-- These go in section 6.

Precedence and Priority (8.)


Which

We will delay shipment in order to have these We will postpone the feature in order to meet first-release goal

features essential?

Other Product Requirements


These are

requirements that are not features (functions) of the product hardware platform requirements - system requirements -- supported host o.s.s, peripherals,

companion software environmental requirements -- temperature, shock, humidity, radiation, usage conditions, resource availability, maintenance issues, type of error recovery applicable standards -- legal, regulatory, communications

Documentation Requirements
What

must be developed to support successful deployment? User Manual? Online Help? Installation guide? Read Me file? Labeling, packaging?

Vision Doc adds basis for SRS

Use Case Internals -- Compare to example in Larman text (p. 68 ff.). Terms: 73-78
Use

Case Name Scope Level Primary Actor Stakeholders & interests Preconditions Success Guarantee (postconditions)

Basic

Flow Alternate Flows (extensions) Error Flows Subflows Special requirements Technology & data variations list Frequency of occurrence Open Issues

Fully Dressed Example: Process Sale, Larman text, p. 68 ff.


Primary Actor: Cashier Stakeholders and Interests: - Cashier: Wants accurate, fast entry, and no payment errors, as cash

drawer shortages are deducted from his/her salary. - Salesperson: Wants sales commissions updated. - Customer: Wants purchase and fast service with minimal effort. Wants proof of purchase to support returns. - Company: Wants to accurately record transactions and satisfy customer interests. Wants to ensure that Payment Authorization Service payment receivables are recorded. Wants some fault tolerance to allow sales capture even if server components are unavailable. Wants automatic and fast update of accounting and inventory.

Fully Dressed Example: Process Sale, Larman text, p. 68 ff. - continued


- Government Tax Agencies: Want to collect tax from every sale.
May be multiple agnecies such as national, state, and county. - Payment Authorization Service: Wants to receive digital authorization requests in the correct format and protocol. Wants to accurately account for their payables to the store. Preconditions: Cashier is identified and authenticated. Success Guarantee (Postconditions): Sale is saved. Tax is correctly calculated. Accounting and Inventory are updated. Commissions recorded. Receipt generated. Payment authorization approvals are recorded.

Fully Dressed Example: Process Sale, Larman text, p. 68 ff. - continued


Main Success Scenario (of Basic Flow): 1. - 10. Extensions (Alternative Flows): *a. *b. 1a 2-4a 3a. 3b. 3c. 3-6a-c 4a 5a-c 6a 7a-f 9a-c

Fully Dressed Example: Process Sale, Larman text, p. 68 ff. cont. Special Requirements: - Touch Screen UI on a large flat panel monitor. Text visible from 1
meter. - Credit auth. response within 30 seconds 90% of the time.

... Technology and Data Variations List: ... Frequency of Occurrence: Could be nearly continuous. Open Issues:
- What are the tax law variations? - Explore the remote service recovery issue. - What customization is needed for different businesses?

Now what -- after development of use case(s)


Look for

Most important for core requirements likely to be implemented


soon

consistency, correctness, completeness

By

See Vision Document State diagrams and tables Event tables Condition tables Domain diagram (UML)

translation to other formats

References
1

Requirements Analysis, Richard Thayer, SMC 10/97 Version 2, 1997 2 IEEE Guide for Software Requirements Specification, IEEE 830-1998 3 Software Requirements:Objects, Functions, and States, Prentice Hall, 1993 4 Software Quality Measurement for Distributed Systems, RADC-TR-83-175

You might also like