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

2. Software Requirements

3. Topics covered Functional and non-functional requirements User requirements System requirements Interface specification The software requirements document

4. Requirements 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).

5. Requirements 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.

6. Types 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

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

8. Functional 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

9. Examples of functional requirements 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.

10. Requirements 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.

11. Non-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.

12. The types of non-functional requirements 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))

13. The types of non-functional requirements 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

14. User 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

15. Problems 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

16. Interface 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

17. Interface 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.

18. The software requirements document 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

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

20. Requirements Engineering Processes

21. Topics covered Feasibility studies Requirements elicitation and analysis Requirements validation Requirements management

22. Feasibility 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

23. Feasibility 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

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

25. Requirements elicitation and analysis 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.

26. Requirements 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.

27. Requirements 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

28. Requirements validation During 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

29. Requirements 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.