requirements engineering lesson 2. terminologies: software acquisition is where requirement...
Post on 13-Dec-2015
254 Views
Preview:
TRANSCRIPT
Requirements EngineeringLesson 2
Terminologies: Software Acquisition is where requirement
engineering significantly meets business strategy.
Software Requirements are description of features and functionalities of the target system.
Requirements are description of the services that a software must provide and the constraints under which it must operate.
Requirements convey the expectations of users from the software product. The requirements can be obvious or hidden, known or unknown, expected or unexpected from client’s point of view.
Types of Requirements User requirements
Statements in natural language plus diagrams of the services that the systems provides and its operational constraints.
Written for customers System requirements
A structured document setting out detailed descriptions of the system services
Written as a contract between client and contractor Software Specifications
A detailed description which can serve as a basis for a design or implementation
Written for developers
Functional and non-functional requirements
Functional Requirements Statements of services that the system should
provide, how the system should react to particular inputs and how the system should behave in particular situations
Describe functionality or system services Depend on the type of software, expected users
and the and the type of system where the software is used.
Functional user requirements may be high-level statements of what the system should do; it should describe the system services in detail.
Functional Requirements Examples: The user should be able to search either
all of the initial set of databases or select a subset from it.
The system shall provide appropriate viewers for the user to read documents in the document store.
Every order shall allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.
Non-functional Requirements Constraints on the services or functions
offered by the system such as timing constraints, constraints on the development process, standards, among others.
It can be categorized as product requirements, organisational requirements, and external requirements.
Non-functional Requirements
Product Requirements Requirements which specify that the
delivered product must behave in a particular way
Portability, reliability, usability, efficiency – space & performance
Organisational Requirements Requirements which are a consequence of
organisational policies and procedures Delivery, implementation and standards
Non-functional Requirements External Requirements
Requirements which arises from factors which are external to the system and its development process
Ethical, interoperability, legislative (safety & privacy)
Requirement Engineering The process to gather software
requirements from client, analyze and document them is known as Requirement Engineering
The goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System Requirements Specification’ document.
Requirement Engineering Process
1. Feasibility Study2. Requirements Gathering3. Software Requirement Specification4. Software Requirement Validation
1. Feasibility Study Feasible – possible, achievable, practical.
1. When the client approaches the organizaiton for getting the desired product,
2. the analysts does a detailed study whether the system and its functionality are feasible to develop.
FS is focused towards goal of the organization. It also explores technical aspects of the project and product such as usability, maintainability, productivity and integration ability.
2. Requirement Gathering If the feasibility is positive towards
undertaking the project. Next phase starts with gathering
requirements from the user. Analysts and engineers communicate
with the client and end-users to know their ideas on what the software should provide and which features they want the software to include.
3. Software Requirement Specification SRS is a document created by system
analysts after the requirements are collected from various stakeholders.
The requirements received from a client are written in natural language.
It is the responsibility of system analyst to document the requirements in technical language so that they can comprehend and useful by the software development team.
SRS should come up with following features:1. User Requirements are expressed in natural
language.2. Technical requirements are expressed in
structured language, which is used inside the organization.
3. Design description should be written in pseudo code
4. Format forms and GUI screens prints5. Conditional and mathematical notations for
DFDs etc.
4. Software Requirement Validation After SRS are developed, the requirements
mentioned in this document are validated. User might ask for illegal, impractical solutions or
experts may interpret the requirements incorrectly. – Costly.
It can be checked against following conditions. If they can be practically implemented If they are valid and as per functionality and domain of
software If there any ambiguities (doubts) If they are complete If they can be demonstrated
Next topic Requirement Elicitation Process Techniques Characteristics
top related