Software Engineering Chapter 3 Software Requirement Specification Eng

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

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) 2

Types of Requirements 1. 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. 2. 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. 3. Software specification: a detailed software description which can serve as basis for design or implementation. It is written for developers. 3

Types of Requirements • Requirement Readers 4

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

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 6

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 7

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

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

Non-Functional Requirements Classification 10

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 11

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

Requirement Engineering • Requirements Engineering is 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. 13

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

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

Requirement Engineering Process 16

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

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

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

Feasibility Studies Feasibility Study involve: 1. information assessment. 2. information collection. 3. report writing. 20

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

Different Aspects of Conducting Feasibility Study A Feasibility Study can be divided as following: 1. Economic Feasibility. 2. Technical Feasibility. 3. Legal Feasibility. 4. Organizational Feasibility. 22

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

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

Documentation of Feasibility Study Feasibility report contains: 1. Introduction. 1. 1 Statement of Problem 1. 2 Implementation Environment. 1. 3 Constraints. 2. Management summery and Recommendations 2. 1 Important findings. 2. 2 comments. 2. 3 Recommendations. 2. 4 Impacts 3. Alternatives: 3. 2 Criteria used in selecting the final approach. 4. System description: 4. 1 abbreviated statement of scope 4. 2 feasibility of allocated elements. 5. Cost benefit analysis 6. Evaluation of technical risk 7. Legal ramifications. 8. Other project specific topics 3. 1 alternative system configurations. 25

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

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

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

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

Techniques for Requirement Elicitation 3. 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. 30

Techniques for Requirement Elicitation 4. 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: 1. Identify Customers (stakeholders). 2. Gathering high-level customer requirements 3. Constructing a set of system features that can satisfy customers needs. 4. Creating a matrix to evaluate system features against customer needs. 31

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

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

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

Techniques for Requirement Elicitation 5. 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. 35

Techniques for Requirement Elicitation 6. 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 capture “who does what” 36

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

Techniques for Requirement Elicitation 38

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

Requirement Analysis Process 40

Requirement Analysis Process Requirement process Activities are 1. Domain understanding 2. Requirements collection 3. Classification 4. Conflict resolution 5. Prioritization 6. Requirements checking 41

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

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

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

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

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

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

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

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

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 nonfunctional requirement only. • It does not contain suggestions, possible solutions or any information rather than the understanding of developers of customers’ needs. 50

Problems without SRS Document 1. Without developing the SRS document, the system would not be implemented according to customer needs. 2. �Software developers would not know whether what they are developing is what exactly required by the customer. 3. �Without SRS document, it will be very much difficult for the maintenance engineers to understand the functionality of the system. 4. �It will be very much difficult for user document writers to write the users’ manuals properly without understanding the SRS document. 51

Goals of SRS document 1. Feedback to Customers: it is the customers assurance that the developers understand the problems to be solved. SRS should be written in a natural language, and include charts, data flow diagrams, decision tables etc. 2. Problem Decomposition: SRS document divides the problem into component parts. This places borders around the problem, solidifies ideas, and help breakdown the problem into its component parts in a orderly fashion. 52

Goals of SRS document 3. Input to Design Specification: SRS serves as the parent document subsequent documents such as the software design specification and statement of work. SRS should contain sufficient delis in the functional system requirements so that a design solution should be made. 4. Production Validation Check: SRS acts as the parent document for testing and validation strategies 53

Who Writes SRS Documents • Usually the system architects and programmers writes SRS documents. • Requirements gathering team consist of programmers, product marketers, system analysis/architects and project managers. 54

Properties of Good SRS Document 1. Concise: The SRS document should be concise and at the same time unambiguous, consistent, and complete. 2. �Structured: A well-structured document is easy to understand modify. in order to make the modifications to the SRS document easy, it is important to make the document well-structured. 3. �Black-box view: It should only specify what the system should do and not stating how to do these. This means that the SRS document should specify the external behavior of the system and not discuss the implementation issues. 55

Properties of Good SRS Document 4. �Conceptual integrity: It should show conceptual integrity so that the reader can easily understand it. � 5. responses to undesired events: It should characterize acceptable responses to undesired events These are called system response to exceptional conditions. 6. �Verifiable: All requirements of the system as documented in the SRS document should be verifiable. This means that it should be possible to determine whether or not requirements have been met in an implementation. 56

Characteristics of SRS Document 1. Correctness. 2. Completeness. 3. Unambiguousness. 4. Verifiability. 5. Modifiability. 6. Traceability. 7. Consistency. 8. Testability. 9. Clarity. 10. Feasibility. 57

Parts of SRS Document The important parts of SRS document are: • Functional Requirements. • Non-Functional Requirements. • Goals of Implementation. 58

Components of SRS Document 1. Interfaces. 2. Functional Capabilities. 3. Performance Levels. 4. Data Structures/Elements. 5. Safety. 6. Reliability. 7. Security/Privacy. 8. Quality. 9. Constraints and limitations. 59

IEEE standard for SRS 60

Uses of SRS 1. Project managers base their estimation of schedule, effort and resources on it 2. Developers need it to develop products 3. Testing group needs it to develop test plan. 4. The maintenance and support staff need it to understand what system should do 5. Document, manuals, etc. are written based on it. 6. Customers use it to determine what product to expect. 7. Can be used to develop training materials 61

Benefits of SRS 1. Establish the basis for agreement between the customers and the suppliers on what the software product is to do 2. Reduce the development effort 3. Provide a basis for realistic estimates of costs and schedules 4. Provide a basis for validation and verification 5. Facilitate transfer of the software product to new users or newmachines 6. Serve as a basis for enhancement requests 62

SRS Validation It is extremely important to detect errors in SRS document before going to other phases of system development, Errors may includes: 1. Omission: some user requirements are not included. 2. Inconsistency: contradiction between user requirements. 3. Incorrect facts. 4. Ambiguity: some requirements have multiple meanings. 63

Data Flow Diagram (DFD) DFD is a graphical representation that provides information flow and transformation between inputs and outputs. DFD purpose is to clarify system requirements and identify major transformation. 64

Data Flow Diagram (DFD) Symbols used in DFD: 65

Data Flow Diagram (DFD) Example of DFD 66

Data Flow Diagram (DFD) Example of DFD 67

Data Flow Diagram (DFD) Rules of DFD: 1. All names should be unique. 2. All data flow are named. 3. DFD is not a flow chart. 4. The direction of flow from source to destination. 5. Process always running. 6. level 0 should represent the system as single process. 7. Primary input and primary output should be carefully identified. 68

Data Dictionary • A catalogue of all elements in a system • DFD shows the flow of information while data dictionary gives the detail of information 69

Data Dictionary Date dictionary store the following information: 1. Name of data item. 2. Aliases (other names for data). 3. Description/purpose. 4. Related data item. 5. Range of values. 6. Data Structure definition. 70

Data Dictionary Notation of Data dictionary: + A plus sign indicates one element is followed by or concatenated with another element. [ ] Square brackets are used to enclose one or more optional elements. | Or / A vertical line or slash stands for "or" and is used to indicate alternatives. {} Curly braces indicate that the element being defined is made up of a series of repetitions of the element(s) enclosed in the brackets. The upper limit on the number of allowable repetitions {}y can be indicated by including an integer superscript on the right bracket. Here y represents an integer and indicates that the number of repetitions cannot be greater than y. ( ) Optional data 71

Data Dictionary Example of Data dictionary: sequence: Mailing-address= name + address + city + zip-code *The address at which the customer can receive mail* repetition: Completed-order = { item-ordered } * A complete customer order * selection: Atm-transaction = [ deposit | withdrawal ] *An customer transaction at an automated teller machine* 72

Data Dictionary Example of Data dictionary: Name: hidden word Alias: secret word Description: the word the player is trying to guess Definition: hidden word = {alphabetic character}30 name: continue choice alias: none description: whether the user wants to play again or not definition continue choice = [yes | no ] 73

Entity-Relationship (ER) Diagram It is a detailed logical representation of data. Its main components: 1. Data Entities. 2. Entities relationships. 3. Entities Attributes. 74

Entity-Relationship (ER) Diagram ER Diagram notations 75

Entity-Relationship (ER) Diagram ER diagram Example 76

Decision Table • Used to express complex conditions and associated action. • Used to model complicated logic. • Decision table consist of 4 four Quadrants: 1. Condition stub. 2. Condition rules 3. Action stub 4. Action rules 77

Decision Table Example: Requirement: A customer requests a cash withdrawal. the ATM machine pays out the amount if the customer has sufficient funds in account or if the customer has the credit granted 78

Decision Table How to create decision table: 1 - Analyze the requirement and create the first column. 79

Decision Table How to create decision table: 2 - Add Columns: Calculate how many columns are needed in the table, fill them with T(True) or F(False). 80

Decision Table How to create decision table: 3 - Reduce the table Mark insignificant values with “-“, then remove the duplicate columns 81

Decision Table How to create decision table: 4 - Determine actions 82

Chapter 3: END OF CHAPTER 83