2 Requirements Engineering It helps software engineers to better understand the problem they will work to solveIt encompasses the set of tasks that lead to an understanding of what the business impact of the software will be, what the customer wants?
3 Types of Requirements Functional Requirements These are statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situationsNon-Functional RequirementsThese are constraints on the services or functions offered by the system. They include timing constraints, constraints on the development process and standards
4 Requirements Engineering Tasks Requirements engineering provides the appropriate mechanism for understanding what the customer wants, analyzing need, assessing feasibility, managing requirements as they are transformed into an operational system and so onRequirements engineering is accomplished through seven functions:InceptionElicitationElaborationNegotiationSpecificationValidationManagement
5 Requirements Engineering Tasks - Inception Inception—ask a set of questions that establish …basic understanding of the problemthe people who want a solutionthe nature of the solution that is desired, andthe effectiveness of preliminary communication and collaboration between the customer and the developer
6 Requirements Engineering Tasks - Elicitation Ask the customer, the user, and othersWhat the objectives for the system?What is to be accomplished?How the system fits into the needs of the business?How the system is to be used on a day-to-day basis?
7 Requirements Engineering Tasks - Elicitation A number of problems that makes the requirements elicitation as a difficult task:Problems of scopeThe boundary of the system is ill-definedProblems of understandingThe customers are not completely sure of what is needed?Problems of volatilityThe requirements change over time
8 Requirements Engineering Tasks - Elaboration Elaboration is an analysis modeling action that is composed of a number of modeling and refinement tasksThe end-result of elaboration is an analysis model that defines the informational, functional, and behavioral domain of the problem
9 Requirements Engineering Tasks - Negotiation It is common for different customers to propose conflicting requirementsThe requirements engineer must reconcile these conflicts through a process of negotiationCustomers, users, and other stakeholders are asked to rank requirements and discuss conflicts in priorityRisks associated with each requirement are identified and analyzedRough “guestimates” of development effort are made and used to assess the impact of each requirement on project cost and delivery time
10 Requirements Engineering Tasks - Specification A specification can be any on of the following:A written documentA set of graphical modelA formal mathematical modelA collection of user scenariosA prototypeThe specification is the final work product produced by the requirements engineerIt serves as the foundation for subsequent software engineering activities
11 Requirements Engineering Tasks - Validation Requirements validation examines the specification to ensure that all requirements have been stated unambiguouslyThe review team that validates requirements includes software engineers, customers, users, other stakeholdersA review mechanism that looks forerrors in content or interpretationareas where clarification may be requiredmissing informationinconsistencies (a major problem when large products or systems are engineered)conflicting or unrealistic (unachievable) requirements
12 Requirements Engineering Tasks – Requirements Management Requirement management is a set of activities that help the project team identify, control, and track requirements and changes to requirements at any time as the project proceedsRequirements management begins with identification. Once requirements are identified, traceability tables are developed
13 Requirements Engineering Tasks – Requirements Management Features traceability tableshows how requirements relate to important customer observable system featuresSource traceability tableidentifies the source of each requirementDependency traceability tableindicates how requirements are related to one anotherSubsystem traceability tablecategorizes requirements by the subsystem that they governInterface traceability tableshows how requirements relate to both internal and external system interfaces
14 Initiating the Requirements Engineering Process - Inception Identify stakeholders“who else do you think I should talk to?”Recognize multiple points of viewWork toward collaborationThe first questionsWho is behind the request for this work?Who will use the solution?What will be the economic benefit of a successful solutionIs there another source for the solution that you need?
15 Eliciting Requirements - Elicitation Collaborative Requirements GatheringIn order to encourage a collaborative, team-oriented approach to requirements gathering, a team of stakeholders and developers work together to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution required
16 Eliciting Requirements - Elicitation Guidelines for collaborative requirements gathering meeting:Meetings are conducted and attended by both software engineer and customersRules for preparation and participation are establishedAn agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideasA “facilitator” ( can be a customer, a developer, or an outsider) controls the meetingA “definition mechanism” ( can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room, or virtual forum) is usedThe goal isto identify the problem,propose elements of the solution,negotiate different approaches, andspecify a preliminary set of solution requirements
17 Eliciting Requirements - Elicitation Quality Function Deployment (QFD)Quality Function Deployment (QFD) is a technique that translates the needs of the customer into technical requirements for softwareQFD concentrates on maximizing customer satisfaction from the software engineering processQFD emphasizes an understanding of what is valuable to the customer and then deploys these values throughout the engineering process
18 Eliciting Requirements - Elicitation Quality Function Deployment Many QFD concepts are applicable to requirements elicitation activity. They are:Function deploymentis used to determine the value of each function that is required for the systemInformation deploymentidentifies both the data objects and events that the system must consume and produceTask deploymentexamines the behavior of the system within the context of its environmentValue analysisis conducted to determine the relative priority of requirements determined during each of the three deployments
19 Elicitation Work Products The work products produced as a consequence of requirements elicitation will vary depending on the size of the system.The work product include:A statement of need and feasibilityA bounded statement of scope for the systemA list of customers, users, and other stakeholdersA description of the system’s technical environmentA list of requirements (organized by function)A set of usage scenarios that provide insight into the use of the systemAny prototype developed to better define requirements
20 Developing Use-CasesThe first step in writing a use-case is to define the set of “actors” that will be involved in the systemActors are different people (or devices) that use the system or product within the context of the function and behavior that is to be describedActors represent the roles that people play as the system operatesAn actor is anything that communicates with the system or product and that is external to the system
21 Developing Use-CasesOnce actors have been defined, use-cases can be developedThe following questions should be answered by a use-case:Who is the primary actor, secondary actor?What are the actor’s goals?What main tasks are performed by the actor?What information does the actor desire from the system?
22 Building the Analysis Model The analysis model is to provide a description of the required informational, functional, and behavioral domains for a computer-based system.The model changes dynamically as software engineers learn more about the system to be built, and stakeholders understand more about what they really require
23 Building the Analysis Model The elements of the analysis modelScenario-based elementsThe system is described from the user’s point of view using scenario based approachUse-cases, use-case diagram, activity diagramClass-based elementsEach usage scenario implies a set of “objects” that are manipulated as an actor interacts with the systemThese objects are categorized into classesClass diagram, collaboration diagram
24 Building the Analysis Model Elements of analysis model (cond…)Behavioral elementsThe analysis model must provide modeling elements that depict behaviorState diagram, sequence diagramFlow-oriented elementsInformation is transformed as it flows through a computer-based systemData-flow diagram
27 Negotiating Requirements The customer and the developer enter into a process of negotiation, where the customer may be asked to balance functionality, performance, and other system characteristics against cost and timeThe best negotiations strive for a “win-win” result. The customer wins by getting the system that satisfies the majority of the customer’s needs, and software team wins by working to realistic and achievable budgets and deadlines
28 Negotiating Requirements The negotiating activities carried at the beginning of each software process iteration are:Identification of the system or subsystem’s key stakeholdersThese are the people who will be involved in the negotiationDetermination of the stakeholders’ “win conditions”Win conditions are not always obviousNegotiate of the stakeholders’ win conditions to reconcile them into a set of win-win conditions for all concernedWork toward a set of requirements that lead to “win-win”
29 Validating Requirements The requirements represented by the model are prioritized by the customer and grouped within requirements packages that will be implemented as software increments and delivered to the customerA review of the analysis model addresses the following questions:Is each requirement consistent with the overall objective for the system?Have all requirements been specified at the proper level of abstraction?Is each requirement bounded and unambiguous?
30 Validating Requirements A review of the analysis model addresses the following questions: (cond…)Do any requirements conflicts with other requirements?Is each requirement testable, once implemented?Does the requirements model properly reflect the information, function, and behavior of the system to be built?