Chapter 04 Requirements Engineering - Part A PDF

Chapter 4 – Requirements Engineering {Part - A} Instructor: Dr. Murad Al-Rajab 1  Analysis Phase PA RT T WO Requirements...

Chapter 4 – Requirements Engineering {Part - A} Instructor: Dr. Murad Al-Rajab 1  Analysis Phase PA RT T WO Requirements Determination Use Case Analysis Process Modeling Chapter 4 Requirements Engineering 2 Chapter 4 Requirements Engineering 3 Learning Objectives  Explain the analysis phase of the SDLC.  Describe the content and purpose of the requirements definition statement.  Classify requirements correctly as business, user, functional, or nonfunctional requirements.  Understand Requirements engineering processes  Define the role that each requirement elicitation technique plays in determining requirements.  Understand the importance of Requirements specification  Understand Requirements validation Chapter 4 Requirements Engineering 4 Key Definitions  The As-Is system is the current system and may or may not be computerized  The To-Be system is the new system that is based on updated requirements  The System Proposal is the key deliverable from the Analysis Phase 5 Chapter 4 Requirements Engineering THE REQUIREMENTS ANALYSIS PHASE 37% of all software development problems are related to requirements. Poorly identified requirements significantly increase the development costs. Chapter 4 Requirements Engineering 6 The Analysis Phase  Analysis refers to breaking a whole into its parts with the intent of understanding the parts’ nature, functions, and interrelationships.  The planning phase deliverables are the key inputs into the analysis phase. Chapter 4 Requirements Engineering 3-7 Overview of the Analysis Phase  Goal is to develop a clear understanding of the new system’s requirements o Understand the “As-Is” system o Identify Improvements o Develop the “To-Be” system concept (Define the Requirements)  Use critical thinking skills to determine the true causes of problems  Apply knowledge of SE and business to outline ways to solve the problems in the new system Chapter 4 Requirements Engineering 8 Determining Requirements Participation by business users is essential Three techniques help users discover their needs for the new system:  Business Process Automation (BPA)  Business Process Improvement (BPI)  Business Process Reengineering (BPR) 9 Chapter 4 Requirements Engineering Determining Requirements (cont’d)  The final deliverables of the analysis phase is the software/ system proposal.  The software/ system proposal is presented to the approval committee in the form of a software/ system walk-through to explain the software/ system in moderate detail.  The deliverables from the analysis phase are the first step in the design of the new software/ system. Chapter 4 Requirements Engineering 10 Requirements and Specification Problem domain Software (Solution) domain Describes problem Specifi Requirements Program Customer cation Specifies Analyzes Develops Software Engineer We receive “customer problem statement,” not the requirements! Chapter 4 Requirements Engineering 11 Understanding requirements REQUIREMENTS ENGINEERING Requirements determination is performed to transform the software/ system request’s high level statement of business requirements (problems) into a more detailed, precise list of what the new software/ system must do to provide the needed value to the business. Chapter 4 Requirements Engineering 12 What does the Customer say? Chapter 4 Requirements Engineering Requirements engineering Requirements engineering is the process of establishing  the services that the customer requires from a system  the constraints under which it operates and is developed Requirements The descriptions of the system services and constraints that are generated during the requirements engineering process Chapter 4 Requirements Engineering 14 Requirements abstraction “If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization’s needs. Once a contract has been awarded, 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. Both of these documents may be called the requirements document for the system.” Chapter 4 Requirements Engineering 15 System stakeholders Any person or organization who is affected by the system in some way and so who has a valid interest Stakeholder types  End users  System managers  System owners  External stakeholders Chapter 4 Requirements Engineering 16 Agile methods and requirements  Many agile methods argue that producing detailed system requirements is a waste of time as requirements change so quickly.  The requirements document is therefore always out of date.  Agile methods usually use incremental requirements engineering and may express requirements as ‘user stories’.  This is practical for business systems but problematic for systems that require pre-delivery analysis (e.g. critical systems) or systems developed by several teams. 17 Requirements Engineering Components  Two questions need to be answered as a first step in identifying requirements: 1. How can we identify the purpose of a system? What are the requirements (features), what are the constraints? 2. What is inside, what is outside the system?  Requirements gathering  (a.k.a. “requirements elicitation”) helps the customer to define what is required: what is to be accomplished, how the system will fit into the needs of the business, and how the system will be used on a day-to-day basis  Requirements analysis  refining and modifying the gathered requirements (Definition of the system in terms understood by the developer)  Requirements specification  documenting the system requirements in a semiformal or formal manner to ensure clarity, consistency, and completeness  Requirements validation Chapter 4 Requirements Engineering 18 What is a Requirement?  A requirement specifies the business functions that the user will be able to perform using the system-to-be in different “situations”, and the kind of experience the user will have during this work  It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.  A statement of what the software/system must do; or  A statement of characteristics the software/ system must have  Types of requirements: o what the business needs (business requirements); o what the users need to do (user requirements); o what the software should do (functional requirements); o characteristics the system should have (nonfunctional requirements); and o how the software/system should be built (software requirements). Chapter 4 Requirements Engineering 19 Types of requirement  Business Requirements  Are the critical activities of an enterprise that must be performed to meet the organizational objective(s) and stay in business.  User requirements  Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.  System requirements (functional and non-functional Req.)  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.  Software specification  A detailed software description which can serve as a basis for a design or implementation. Written for developers Chapter 4 Requirements Engineering 20 Focuses of Information Collection Activities What is the business, the current business situation, and how does it operate? What is the system’s environment or context? What are existing business processes, their input and output, and how do they relate to each other? What are the problems with the current system? What are the business or product goals? Who are the users of the current and future systems, respectively? What do the customer and users want, and what are their business priorities? What are the quality, performance, and security considerations? 21 User Requirements  What the user needs to do to complete a needed job or task  Focus on user tasks that are integral to business operations  Understanding user tasks helps reveal ways that the new software/system can support those tasks  These user requirements describe tasks that the users perform as an integral part of the business’ operations, such as: “Schedule a client appointment”; “Place a new customer order”; “Re-order inventory”; “Determine available credit”; and “Look up account balances.” Chapter 4 Requirements Engineering 22 User Requirements Example 1. Schedule a Client Appointment  The Sales Representative should be able to schedule appointments with clients through the system. This includes selecting a date, time, and specifying the client involved. 2. Place a New Customer Order  The Sales Representative must have the capability to create new customer orders within the system. This involves entering order details, selecting products, and specifying the customer information. 3. Re-order Inventory  The system should provide functionality for the Sales Representative to reorder inventory items. This includes identifying low stock items and generating replenishment orders. 4. Determine Available Credit  The Sales Representative should be able to check the available credit for a specific customer account. 5. Look Up Account Balances  The system should allow the Sales Representative to retrieve account balances for specific accounts. © 2015 John Wiley & Sons. All Rights Reserved. 23 Functional and non-functional requirements Chapter 4 Requirements Engineering 24 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 for example “The implementation language must be Java “ Chapter 4 Requirements Engineering 25 Functional Requirements  A process the software/system should perform as a part of supporting a user task, or  Information the software/system should provide as the user performs a task  Specify the support the software/system will provide to the user in fulfilling his/her work tasks  Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. Chapter 4 Requirements Engineering 26 Functional requirements  What inputs the system should accept  What outputs the system should produce  What data the system should store that other systems might use  What computations the system should perform  The timing and synchronization of the above 27 Functional requirements  Describe functionality or system services.  Depend on the type of software, expected users and the type of system where the software is used.  Functional user requirements may be high-level statements of what the system should do BUT functional system requirements should describe the system services in detail. Chapter 4 Requirements Engineering 28 More on Functional Requirements o Process-oriented o Information-oriented © 2015 John Wiley & Sons. All Rights Reserved. 29 Examples of functional requirements  The system shall provide appropriate viewers for the user to read documents in the document store.  Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.  The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. Chapter 4 Requirements Engineering 30 Functional Requirements Examples 1. User Authentication:  The system must allow users to create accounts, log in, and securely manage their authentication credentials. 2. Search Functionality:  The system should provide a search feature that allows users to find specific information or items within the application. 3. Record and Store Customer Orders:  The system must have the capability to record and store details of customer orders, including product details, quantity, and customer information. 4. Generate and Send Email Notifications:  The system should automatically generate and send email notifications to users for important events or updates, such as order confirmations or password resets. 5. User Permissions and Access Control:  The system should enforce role-based access control, ensuring that users only have access to the functionalities and data relevant to their roles. © 2015 John Wiley & Sons. All Rights Reserved. 31 Functional Requirements Examples (Cont.) 6. Inventory Management:  The system must allow users to add, edit, and remove inventory items, as well as track stock levels and generate reports on inventory status. 7. Process Payments:  The system should facilitate secure payment processing for customer orders, supporting multiple payment methods. 8. Generate Reports:  The system must have the capability to generate various reports, such as sales reports, inventory status reports, and financial statements. © 2015 John Wiley & Sons. All Rights Reserved. 32 Requirements as User Stories A User Story is a requirement expressed from the perspective of an end-user goal. User Stories follow the same format. They are assembled in a Ordered Requirements List. A User Story is a well- The format of the User Story is as follows: expressed requirement. Its format has become the As a < role>, I need, So that most popular way of expressing requirements These two examples demonstrate User Stories at different levels. in Agile At a project level As a Manager, I need to improve customer service So that we retain our customers. At a detailed level As an Investor, I need to see a summary of my investment accounts, So that I can decide where to focus my attention. As a tenant, I can unlock the doors to enter my apartment. user-role capability business-value (benefactor) 33 Requirements imprecision  Problems arise when functional requirements are not precisely stated.  Ambiguous requirements may be interpreted in different ways by developers and users.  Consider the term ‘search’ in the following requirement  User The intention user shall – to be able search searchfor a patient either name all of the across initial set of all appointments databases or selectina all clinics; subset from it.  Developer interpretation – search for a patient name in an individual clinic. User chooses clinic then search. Chapter 4 Requirements Engineering 34 Requirements imprecision (Cont.) 1. User Intention (Search Across All Clinics): 1. User Action: The user wants to find a patient named "John Doe" and see if he has appointments in any clinic, regardless of which clinic it is. 2. Expected Outcome: The system should provide a list of appointments for "John Doe" across all clinics. 2. Developer Interpretation (Search in a Specific Clinic): 1. User Action: The user chooses a specific clinic (e.g., "Main Street Clinic") and then performs a search for a patient named "John Doe." 2. Expected Outcome: The system will only display appointments for "John Doe" within the selected clinic, in this case, "Main Street Clinic." © 2015 John Wiley & Sons. All Rights Reserved. 35 Requirements completeness and consistency In principle requirements should be both complete and consistent Complete  They should include descriptions of all facilities required Consistent  There should be no conflicts or contradictions in the descriptions of the system facilities In practice, it is very difficult or impossible to produce a complete and consistent requirements document Chapter 4 Requirements Engineering 36 Non-functional requirements (or quality requirements)  Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. 37 Nonfunctional Requirements (NFR)  Behavioral properties the software must have o Operational – physical and technical operating environment o Performance – speed (response time), capacity, and reliability needs, availability o Security – access restrictions, needed safeguards o Cultural and political – issues that will affect the final system  Nonfunctional requirements will return back in more details in Chapter 8 (Architecture Design)  The term FURPS+ refers to the non-functional system properties: o Functionality (security), Usability, Reliability, Performance , Supportability Chapter 4 Requirements Engineering 38 Metrics for specifying nonfunctional requirements Property Measure Speed Processed transactions/second User/event response time Screen refresh time Size Mbytes Number of ROM chips Ease of use Training time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems Chapter 4 Requirements Engineering 39 More on Nonfunctional Requirements o Behavioral properties the system must have 40 Non-functional classifications  Product requirements  Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.  Organisational requirements  Requirements which are a consequence of organisational 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. Chapter 4 Requirements Engineering 41 Types of nonfunctional requirement Chapter 4 Requirements Engineering 42 Non-functional requirements implementation  Non-functional requirements may affect the overall architecture of a system rather than the individual components.  For example, to ensure that performance requirements are met, you may have to organize the system to minimize communications between components.  A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required.  It may also generate requirements that restrict existing requirements. Chapter 4 Requirements Engineering 43 Non-functional requirements Chapter 4 Requirements Engineering 44 45 One of the most common mistakes made by new software engineers, is to confuse functional and nonfunctional requirements. Assume that you received the following list of requirements for a sales system: Requirements for Proposed System: The system should… 1. be accessible to Web users. 2. include the company standard logo and color scheme. 3. restrict access to profitability information. 4. include actual and budgeted cost information. 5. provide management reports. 6. include sales information that is updated at least daily. 7. have 2-second maximum response time for predefined queries and 10-minute maximum response time for ad hoc queries. 8. include information from all company subsidiaries. 9. print subsidiary reports in the primary language of the subsidiary. 10. provide monthly rankings of salesperson performance. QUESTIONS: 1. Which requirements are functional business requirements? Provide two additional examples. 2. Which requirements are nonfunctional business requirements? What kind of nonfunctional requirements are they? Provide two additional examples. Chapter 4 Requirements Engineering 46 Documenting Requirements  Requirements definition report o Text document listing requirements in outline form o Organized in logical groupings o Priorities may be included  Key purpose is to define the project scope o what is included o what is not included. 47 The Requirements Definition Statement  The requirements definition statement—usually just called the requirements definition—is a straightforward text report that simply lists the functional and non- functional requirements in an outline format.  The following example shows a sample requirements definition for Holiday Travel Vehicles, a dummy recreational vehicle dealership. 48 © 2015 John Wiley & Sons. All Rights Reserved. 49 50 Another Example A sample requirements definition for an appointment system for a typical doctor’s office. 51 Requirements Engineering Processes Chapter 4 Requirements Engineering 52 53 Requirements engineering processes  The processes used for RE vary widely depending on the application domain, the people involved and the organization developing the requirements.  However, there are a number of generic activities common to all processes  Requirements elicitation;  Requirements analysis;  Requirements specification;  Requirements validation;  Requirements management.  In practice, RE is an iterative activity in which these processes are interleaved. Chapter 4 Requirements Engineering 54 A spiral view of the requirements engineering process 55 The Process of Determining Requirements  Both business and IT perspectives are needed to determine requirements during the analysis phase.  The most effective approach is to have both business people; Software Engineers, and analysts working together to determine requirements.  The software engineer and the analyst must also consider how best to elicit the requirements from the stakeholders.  The process of determining requirements continues throughout the analysis phase, and the requirements definition evolves over time. Chapter 4 Requirements Engineering 56 Ways to discover requirements REQUIREMENTS ELICITATION TECHNIQUES 57 Requirements elicitation and analysis  Sometimes called requirements elicitation or requirements discovery.  May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders. Chapter 4 Requirements Engineering 58 Problems of requirements elicitation  Stakeholders don’t know what they really want.  Stakeholders express requirements in their own terms.  Different stakeholders may have conflicting requirements.  Organisational and political factors may influence the system requirements.  The requirements change during the analysis process. New stakeholders may emerge and the business environment may change. Chapter 4 Requirements Engineering 59 Requirements elicitation  Software engineers work with a range of system stakeholders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc.  Stages include:  Requirements discovery,  Requirements classification and organization,  Requirements prioritization and negotiation,  Requirements specification. Chapter 4 Requirements Engineering 60 Process activities  Requirements discovery  Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.  Requirements classification and organisation  Groups related requirements and organises them into coherent clusters.  Prioritisation and negotiation  Prioritising requirements and resolving requirements conflicts.  Requirements specification  Requirements are documented and input into the next round of the spiral. Chapter 4 Requirements Engineering 61 References  Software Engineering, 10th Edition, Ian Sommerville  Object-Oriented Software Engineering Using UML, Patterns, and Java, 3rd Edition, 2013, Bernd Bruegge, Allen H. Dutoit.  Systems analysis and design, 6th edition, Dennis, wixom, and roth  A Concise Introduction to Software Engineering, 2008, Pankaj Jalote  Software Engineering, 2nd Edition, David C. Kung Chapter 4 Requirements Engineering 62