Anda di halaman 1dari 32

Requirement Engineering

Functional and Non-Functional Requirements


Functional requirements Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. Non-functional requirements constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Domain requirements Requirements that come from the application domain of the system and that reflect characteristics of that domain

Non-Functional requirements
Define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular CASE system, programming language or development method Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless

Non-Functional classifications
Product requirements Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. Organisational requirements Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc. External requirements Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

Non-Functional Requirement types


Non-functional requir ements Product requir ements Or ganizational requir ements External requirements

Ef ficiency requir ements

Reliability requir ements

Portability requirements

Interoperability requirements

Ethical requirements

Usability requirements

Delivery requirements

Implementation requir ements

Standards requirements

Legislative requirements

Performance requirements

Space requir ements

Privacy requirements

Safety requirements

Requirements measures
Prope rty Speed Size Ease of use Reliability Measure Processed transactions/second User/Event response time Screen refresh t ime K Byt es Number of RAM chips Training t ime Number of help frames Mean time t o failure Probabilit y of unavailability Rate of failure occurrence Availabilit y Time to restart after failure Percent age of events causing failure Probabilit y of dat a corruption on failure Percent age of t arget dependent statements Number of t arget syst ems

Robustness Port abilit y

Stake Holders
Stake holders different people who would be interested in the software. Management carries a lot of weight, but are they the actual users? Acceptance of the software depends upon whom? Stakeholders have very general and vague requirements. Some times they trivialize things. Different stake holders have different requirements sometimes even conflicting. Analysis takes place in an organizational context internal politics may influence requirements.

Stake Holders
Management Marketing
Provides Business Requirements and Project Parameters Specifies High Level Requirements

Software Requirements allocates system requirements to software describe user requirements and quality attributes specifies hardware interfaces the software must respect

Systems Engineering

Users

Hardware Engineering

Stake holders - User classes


A study of over 8300 projects revealed that the top two reasons for any project failure are lack of user input and incomplete requirements.

Example of menu driven system for power users


supposed to replace the existing system but failed because of this reason.

Requirement Statement versus Requirement Specification

Requirement Statement Characteristics


Complete - Each requirement must fully describe the functionality to be
delivered. built.

Correct - Each requirement must accurately describe the functionality to be


Feasible - It must be possible to implement each requirement within the
known capabilities and limitations of the system and its environment. Necessary -Each requirement should document something that the customer really need or something that is required for conformance to an external system requirement or standard. Prioritized - Assign an implementation priority to each requirement, feature or use case to indicate how essential it is to a particular product release. Unambiguous - All readers of a requirement statement should arrive at a single, consistent interpretation of it. Verifiable - Examine each requirement to see whether you can devise a small number of tests or use other verification approaches, such as inspection or demonstration, to determine whether the requirement was properly implemented.

Requirement Specification Characteristics


Complete - No requirement or necessary information should be missing. Consistent - Should not conflict with other software or higher-level system or business requirements. Modifiable - One must be able to revise the SRS when necessary and maintain a history of changes made to each requirement. Traceable - One should be able to link each requirement to its origin and to the design elements, source code, and test cases that implement and verify the correct implementation of the requirement.

Relationship of Several components of Software Requirements


Business Requirements

Vision and Scope Document

User Requirements

Quality Attributes

Use Case Document

Other Non Functional Requirements

System Requirements

Functional Requirements

Constraints

Functional Specification Document

Mixed level of abstraction


The purpose of the system is to track the stock in a warehouse. When a loading clerk types in the withdraw command he or she will communicate the order number, the identity of the item to be removed, and the quantity removed. The system will respond with a confirmation that the removal is allowable.

Business Requirements
Example of conflicting business requirements page 97 Priority setting = Msword

An Example
In this example an embedded system is to be developed for a booth. This system will be sold to the retail stores and will be used by the store customers.

Business Requirements Developers View


Leasing or selling this booth to the retailer. Selling consumable through this booth to the customer. Attracting customers to the brand. Modifying the nature of the historical developer-customer relationship.

Business Requirements Retailers View


Making money from customer use of this booth. Attracting more customers to the store. Saving money of the booth replaces manual operations.

Conflicting Objectives
The developer might want to establish a high-tech and exciting new direction for the customer, while the retailer wants a simple, turnkey system, and the customer wants convenience and features.

Vision Statement
Example chemical tracking system Assumptions and dependencies Scope

Vision Statement
An Example

The Chemical Tracking System will allow scientists to request containers of chemicals to be supplied by the chemical stockroom or by vendors. The location of every chemical container within the company, the quantity of material remaining in it, and the complete history of each containers location and usage will be known by the system at all times. The company will save 25% on chemical cost by

Vision Statement
An Example - continued

fully exploiting chemicals already available within the company, by disposing of fewer partially used or expired containers, and by using a standard chemical purchasing process. The Chemical Tracking System will also generate all reports required to comply with federal and state government regulations that require the reporting of chemical usage, storage and disposal.

Defining the scope Context Diagram


A picture is worth thousand words Example chemical tracking system

Context Diagram

Enters the Development Team

Sources of Requirements

Customer-Developer Relationship
Excellent software products are the result of a well-executed design based on excellent requirements. High quality requirements result from effective communication and coordination between developers and customers.

Building a relationship
Learn about the business
It is not a computer science problem the problem lies in a different domain than computer science and you must understand it before you can solve it.
Personal experience SFA tool for Telecom

Speak the user language


Document should be structured and written in a way that the customer finds it easy to read and understand.

Use Cases

Use Case Model


Use Case Actor

Use Case Model


Use Case
Boundaries of the system are defined by functionality that is handled by the system. Each use case specifies a complete functionality (from its initiation by an actor until it has performed the requested functionality).

Actor
An entity that has an interest in interacting with the system a human or some other device or system.

Use Case Model


A use must always deliver some value to the actor.

Anda mungkin juga menyukai