الثالثة الثالثة المحاضرة المحاضرة

Software RequirementsSoftware Requirements

Topics coveredTopics covered

• Functional and non-functional requirements

• User requirements

• System requirements

• Interface specification

• The software requirements document

Requirements engineeringRequirements engineering

• - The requirements for a system are the descriptions of the services provided by the system and its operational constraints

• - These requirements reflect the needs of customers for a system that helps solve some problem such as controlling a device, placing an order or finding information.

• - The process of finding out, analysing, documenting and checking these services and constraints is called requirements engineering (RE).

Requirements engineeringRequirements engineering

• - the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do.

• - Some of the problems that arise during the requirements engineering process are a result of failing to make a clear separation between these different levels of description. and distinguish between user requirements and system requirements .

Types of requirementTypes of requirement

• User requirements– Statements in natural language plus diagrams

of the services the system provides and its operational constraints.

• System requirements– A structured document setting out detailed

descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor

Functional and non-functional Functional and non-functional requirementsrequirements

• 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.

Functional requirementsFunctional requirements

- The functional requirements for a system describe what the system should do.

- These requirements depend on the type of software being developed, the expected users of the software and the general approach taken by the organization when writing requirements.

- functional system requirements describe the system function in detail, its inputs and outputs, exceptions

Examples of functional Examples of functional requirementsrequirements

• The LIBSYS system-:• Functional requirements for a software system

may be expressed in a number of ways. For example, functional requirements for a university library system called LIBSYS, used by students and faculty to order books and documents from other libraries

• library system that provides a single interface to a number of databases of articles in different libraries.

• Users can search for, download and print these articles for personal study.

Requirements imprecisionRequirements imprecision

- Imprecision in the requirements specification is the cause of many software engineering problems.

- In principle, the functional requirements specification of a system should be both complete and consistent.

- Completeness means that all services required by the user should be defined

- Consistency means that requirements should not have contradictory definitions.

Non-functional requirementsNon-functional requirements

• Non-functional requirements, as the name suggests, are requirements that are not directly concerned with the specific functions delivered by the system.

• They may relate to emergent system properties such as reliability, response time , they may define constraints on the system such as the capabilities of I/O devices and the data representations used in system interfaces.

• they are often more critical than individual functional requirements. System users can usually find ways to work around a system function that doesn’t really meet their needs.

The types of non-functional The types of non-functional requirementsrequirements

• 1- Product requirements :- These requirements specify product behavior.

((Examples include performance requirements on how fast the system and how much memory ; reliability requirements that set out the failure rate and portability requirements; and usability requirements((

2- Organizational requirements:- These requirements are derived from policies and

procedures in the customer’s and developer’s organization.

(( Examples include process standards that must be used; implementation requirements such as the programming language or design method used))

The types of non-functional The types of non-functional requirementsrequirements

• 3- External requirements:- This broad heading covers all requirements that

are derived from factors external to the system and its development process. These may include:-

1- interoperability requirements that define how the system interacts with systems in other organizations

2- legislative requirements that must be followed to ensure that the system operates within the law

User requirementsUser requirements

• The user requirements for a system describe the functional and nonfunctional requirements so that they are understandable by system users without detailed technical knowledge.

• if you are writing user requirements, you should not use software jargon. You should write user requirements in simple language, with simple tables and forms and intuitive diagrams

Problems with natural languageProblems with natural language

• various problems can arise when requirements are written in natural language sentences in a text document

1- Lack of clarity :- It is sometimes difficult to use language in a precise and unambiguous way without making the document wordy and difficult to read

2-Requirements confusion:- Functional requirements, non-functional requirements, system goals and design information may not be clearly distinguished.

3-Requirements amalgamation :- Several different requirements may be expressed together

Interface specificationInterface specification

• all software systems the new system and the existing systems must work together ,must of the interfaces of existing systems have to be precisely specified. These specifications should be defined early in the process and included in the requirements document

Interface specificationInterface specification

• There are three types of interface that may have to be defined:-

• 1. Procedural interfaces:- where existing programs or sub-systems offer a range of services that are accessed by calling interface procedures. These interfaces are sometimes called Application Programming Interfaces (APIs)

• 2. Data structures that are passed from one sub-system to another. Graphical data models are the best notations for this type of description

• 3. Representations of data (such as the ordering of bits) that have been established for an existing sub-system.

The software requirements The software requirements documentdocument

• The requirements document is the official statement of what is required of the system developers .Should include both a definition of user requirements and a specification of the system requirements. It is NOT a design document. it set of WHAT the system should do rather than HOW it should do it

الرابعة الرابعة المحاضرة المحاضرة

Requirements Engineering Requirements Engineering ProcessesProcesses

Topics coveredTopics covered

• Feasibility studies

• Requirements elicitation and analysis

• Requirements validation

• Requirements management

Feasibility studiesFeasibility studies

• - the requirements engineering process should start with a feasibility study.

• - The input to the feasibility study is a set of preliminary business requirements

• - an outline description of the system and how the system is intended to support business processes

Feasibility studiesFeasibility studies

A feasibility study is a short, focused study that aims to :-

• 1- Does the system contribute to the overall objectives of the organization

• 2. if the system be implemented using current technology and within given cost and schedule constraints

• 3. Can the system be integrated with other systems which are already in place

Feasibility studiesFeasibility studies

• Carrying out a feasibility study involves information assessment, information collection and report writing. The information assessment phase already the information that is required to answer the three questions set out above

• In a feasibility study you may consult information sources such as :-

- the managers of the departments where the system will be used

- software engineers who are familiar with the type of system that is proposed

- technology experts and end-users of the system

Requirements elicitation and Requirements elicitation and analysisanalysis

• Sometimes called requirements elicitation or requirements discovery. The next stage of the requirements engineering process

• Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints.

• May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.

Requirements discoveryRequirements discovery

• The process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information.

• Sources of information include documentation, system stakeholders and the specifications of similar systems.

Requirements validationRequirements validation

- Requirements validation is important because errors in a requirements document can lead to extensive rework costs when they are discovered during development or after the system is in service. The cost of fixing a requirements problem by making a system change is much greater than repairing design or coding errors

Requirements validationRequirements validationDuring the requirements validation process, checks should be carried in the

requirements document. These checks include:-

1- Validity checks:- user may think that a system is needed to perform certain functions.

2- Consistency checks :- Requirements in the document should not conflict.

3- Completeness checks :- The requirements document should include requirements, which define all functions, and constraints intended by the system user

4- Realism checks :- Using knowledge of existing technology, the requirements should be checked to ensure that they could actually be implemented. These checks should also take account of the budget and schedule for the system development.

5. Verifiability:- To reduce the potential for dispute between customer and contractor, system requirements should always be written so that they are verifiable

Requirements managementRequirements management

• Requirements management is the process of understanding and controlling changes to system requirements.

• you should start planning how to manage changing requirements during the requirements elicitation process.