Software Engineering

1. Software Engineering Chapter 3: Software Requirement Specification Eng. Sultan M. Al-Rushdan

2. Software Requirements and its Types • The requirements of a system are the descriptions of the services provided by the system and its operational constraints • The Process of finding out, analyze, documenting and checking these services and constraints is called Requirement engineering (RE)

3. Types of Requirements • User Requirements: are statements in natural language plus diagram of what services the system is expected to provided and constraint under which it must operate. • System Requirements: the set of system’s functions, services and operational constraints in detail. System requirements document (functional specification) should be precise and it should define exactly what is to be implemented. • Software specification: a detailed software description which can serve as basis for design or implementation. It is written for developers.

4. Types of Requirements • Requirement Readers

5. Functional and Non-functional Requirements Software system requirements usually classified into: • Functional Requirements. • Non-Functional Requirements

6. Functional Requirements • Describe what system should do. • It depend on the type of software being developed, the expected users and approach taken by organization. • Describe the system functions in detail, its input and output, exceptions etc. • Statements of services the system should provide. • How the system should react to inputs and events. • In some cases what system should not do

7. Functional Requirements Functional Requirement of a system should be both complete and consistent. • Completeness: means that all services required by user should be defined. • Consistency:means that requirements should not have contradictory definitions. In practice, it is impossible to produce a complete and consistent requirements document

8. Non-Functional Requirements • Requirement that are not directly concerned with the specific functions of the system. • They may concern with system property such as reliability, response time and store occupancy • They may define system constraints such as capabilities of I/O devices. • They are rarely associated with individual system features. • Concern manly with system features such as performance, security, availability, etc.

9. Non-Functional Requirements Classification • Product requirements: Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. • Organizational requirements: Requirements which are a consequence of organizational 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.

10. Non-Functional Requirements Classification

11. Domain requirements • Derived from the application domain and describe system characteristics and features that reflect the domain • Domain requirement are important because they reflect fundamentals of the application domain. • If domain requirements are not satisfied, the system may be unworkable

12. Domain requirements Problems • Understandability: domain requirement are expressed in the language of the application domain, this is often not understood by software engineers. • Implicitness: Domain specialists understand the area so well that thay do not think of making the domain requirements explicit.

13. Requirement Engineering • Requirements Engineeringis the systematic use of proven principles, techniques, languages, and tools for the cost effective analysis, documentation, and on-going evolution of user needs and the specification of the external behavior of a system to satisfy those user needs. • Requirement Engineering produces one large document written in natural language describe what system should do without describing how to do it.

14. Requirement Engineer • Requirement Engineer is a man who is responsible for creating requirement document, and make sure documented requirement are met through stages od project. • Requirement Engineer must have knowledge in: • Using CASE tools. • Using general Modeling techniques. • Using modeling languages and ability to choose the best one for a given problem. • Using management and traceability tools.

15. Requirement Engineering Process • The goal of Requirements Engineering Process is to create and maintain a system requirement document. • The overall process include four high-level requirement engineering sub-process: • Feasibility study. • Elicitation and analysis. • Specification. • Validation.

16. Requirement Engineering Process

17. Requirement Engineering Process • The Requirements Engineering Process involve the following activities: • Feasibility Study. • Requirement Elicitation. • Requirement Analysis. • Requirement Documentation. • Requirement Validation. • Requirement Management.

18. Feasibility Studies • A feasibility study decides whether or not the proposed system is worthwhile. • Is defined as an evaluation or analysis of the potential impact of proposed project or program.

19. Feasibility Studies A feasibility Study aims to answer the following questions: • does the system contributes to the overall organizational objectives? • Can the system can be engineered using current technology and within budget? • Can the system can be integrated with other systems that are used?

20. Feasibility Studies Feasibility Study involve: • information assessment. • information collection. • report writing.

21. Feasibility Studies Questions for people in the organization: • How would the organization cope if this system was not implemented? • What are the problems with current processes and how would a new system help alleviate them? • What direct contribution will the system make to the business objectives and requirements? • Can information be transferred to and from other organizational systems? • Does the system require technology that has not previously been used in the organization? • What must be supported by the system and what need not be supported?

22. Different Aspects of Conducting Feasibility Study A Feasibility Study can be divided as following: • Economic Feasibility. • Technical Feasibility. • Legal Feasibility. • Organizational Feasibility.

23. Different Aspects of Conducting Feasibility Study • Economic Feasibility: give the economical justification for new system. • Technical Feasibility: • Understand the different technologies involved. • Find out if the organization current process requires technology • Fid out if the necessary experise exist to use technology • Legal Feasibility. • Organizational Feasibility.

24. Different Aspects of Conducting Feasibility Study • Legal Feasibility: be ascertained wither the new system may result in any infringement, violation, contracts or liabilities. • Organizational Feasibility: what are the issues in hand and what are the management expectations.

25. Documentation of Feasibility Study Feasibility report contains: • Introduction. 1.1 Statement of Problem 1.2 Implementation Environment. 1.3 Constraints. • Management summery and Recommendations 2.1 Important findings. 2.2 comments. 2.3 Recommendations. 2.4 Impacts • Alternatives: 3.1 alternative system configurations. 3.2 Criteria used in selecting the final approach. • System description: 4.1 abbreviated statement of scope 4.2 feasibility of allocated elements. • Cost benefit analysis • Evaluation of technical risk • Legal ramifications. • Other project specific topics

26. Requirement Elicitation • Requirement elicitation is the process of extracting the information from users, customers, and group of people. • This is the most difficult, critical, error prone and communication intensive step in software development.

27. Requirement Elicitation Requirement Elicitation include the following activities: • Knowledge of general area where system is applied. • The details of the specific customer problem where the system will be applied must be understood. • Interaction of system with external environment. • Detailed investigation of user needs. • Define the constraints for system development.

28. Requirement Elicitation Process A general process of requirement elicitation includes: • Identify all stakeholders who could be sources of requirements. • Ask relevant questions in order to gain understanding of the problem. • Analyze the information looking for conflicts, ambiguities, inconsistencies or unresolved issues. • Confirm understanding of requirement with stakeholder. • Create a requirement statements.

29. Techniques for Requirement Elicitation • Interviews: most popular techniques to understand problems, may be open ended or agenda, where developers try to understand the system by interviewing stakeholders. • Brainstorming: a group technique used to understand requirements, it promote creative thinking, generate new Ideas and share views.

30. Techniques for Requirement Elicitation • Facilitated Application Specification Technique(FAST): joint team of developers and customers work together to identify the problem, propose elements of solution, negotiate approaches and prepare a set of solution requirements.

31. Techniques for Requirement Elicitation • Quality Function Deployment: is a requirement engineering techniques that focus on quality, it is used to produce a technical requirement from user requirement. Stages are: • Identify Customers (stakeholders). • Gathering high-level customer requirements • Constructing a set of system features that can satisfy customers needs. • Creating a matrix to evaluate system features against customer needs.

32. Techniques for Requirement Elicitation • Quality Function Deployment: is the main focus is the House of Quality (HOQ), QFD have 4 stages

33. Techniques for Requirement Elicitation House of Quality: is a matrix that consists of sub matrices that are related to each other

34. Techniques for Requirement Elicitation • Customer Requirements is the voice of customer. • Planning matrix customer view on existing product • Technical Requirements: how company will meet the customer requirements. • Inter-relationships matrix: shows how well features address customer needs. • Roof: correlation matrix it shows how requirement conflict with each other. • Targets: summarizes the conclusions of planning matrix it includes: • Technical priorities • Competitive benchmarks • Targets.

35. Techniques for Requirement Elicitation • Joint Application Development (JAD): is designed for development of large computer systems. The goal is to involve all stakeholders in design phase via highly structured and focused meetings.

36. Techniques for Requirement Elicitation • Use-Case Approach:use a combination of text and pictures to improve the understand of requirements. It describe what of the system not how. Use case uses the following components: Actor: an actor or external agent lies outside the system model but interact with it, actor may be person, machine or information system Use cases: is a process initiated by actor to achieve some task, and completed successfully when the goal is satisfied, it describe the sequence of steps between actor and system. use case capture “who does what”

37. Techniques for Requirement Elicitation the following steps outline a process for creating use case: • Identify all different users. • Create a user profile for each category of users including roles played by user for each role identify goals the system should support. • Create a use case for each goal. • Structure the use case. • Review and validate with user.

38. Techniques for Requirement Elicitation

39. Requirement Analysis Task performed during requirement analysis: • Categorizing and organizing the requirements into respective subsets. • Establish the relationships among requirements. • Further examination for consistency, ambiguity, useless requirements are omitted. • Requirements are ranked as per user needs

40. Requirement Analysis Process

41. Requirement Analysis Process Requirement process Activities are • Domain understanding • Requirements collection • Classification • Conflict resolution • Prioritization • Requirements checking

42. Requirement Documentation • Requirement documentation is written after elicitation and analysis, document called software requirement specification (SRS). • SRS is specifications of a system that describes the system functionalities, performance and constraints of the system.

43. Requirements Validation • The objective is to certify that the SRS document is an acceptable document of the system being developed. • In requirement validation the requirement error is being fixed. • Requirements error costs are high so validation is very important. • Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.

44. Requirement Validation Techniques • Requirements reviews: a Systematic manual analysis of the requirements. Requirement review can be: • Informal review: involve developers discussing requirement with as many stakeholder as possible. • Formal review: the development team should walk the client through requirement. The review should check consistency and completeness.

45. Requirement Validation Techniques • Requirements reviews: reviewer checks also for: • Verifiability. Is the requirement realistically testable? • Comprehensibility. Is the requirement properly understood? • Traceability. Is the origin of the requirement clearly stated? • Adaptability. Can the requirement be changed without a large impact on other requirements?

46. Requirement Validation Techniques • Prototyping: Using an executable model of the system to check requirements. • Test-case generation: Developing tests for requirements to check Verifiability, Comprehensibility,Traceability,Adaptability

47. Requirement management • Requirements management is the process of managing changing requirements during the requirements engineering process and system development • It is a systematic approach to eliciting, organizing and documenting the requirement.

48. Requirement management Enduring and volatile requirements: • Enduring requirements: Stable requirements derived from the core activity of the customer organization. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain models. • Volatile requirements: Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy.

49. Requirement Management Process During the requirements engineering process, you have to plan: • Requirements identification: How requirements are individually identified. • A change management process: The process followed when analyzing a requirements change. • Traceability policies: The amount of information about requirements relationships that is maintained. • CASE tool support: The tool support required to help manage requirements change.

50. Software Requirements Specifications (SRS) Document • SRS is the output of requirements analysis • SRS should be consistence, correct, unambiguous and complete • It is not a design document, it describes what system should do rather than how to do it. • It contains only functional and non-functional requirement only. • It does not contain suggestions, possible solutions or any information rather than the understanding of developers of customers’ needs.