PowerPoint Presentation

Chapter 4:Requirements Engineering

Problems with requirements practices Requirements engineering tasks Inception Elicitation Elaboration Negotiation Specification Validation Requirements management

A Customer walks into your office and says;

I know you think you understand what I said, but what you dont understand is what I said is not what I mean.

Invariably this happens late in the project, after deadline commitments have been made, reputations are on the line, and serious money is at stake.2Requirement EngineeringRequirements engineering (RE) refers to the process of defining, documenting and maintaining requirements.

Requirement Engineering (RE) is the science and discipline concerned with analyzing and documenting requirements.3Starter QuestionsWhat is a "requirement"?

How do we determine the requirements?4

Types of RequirementsFunctionalex - it must email the sales manager when an inventory item is "low"Non-Functionalex - it must require less than one hour to runExplicitex required featuresImpliedex software qualityForgottenex exists in current processUnimagined

5QuestionsWhat makes a particular requirement good or bad?

Why is requirements engineering difficult?6

Requirements of RequirementsClearMeasurableFeasibleNecessaryPrioritizedConcise7The Problems with our Requirements PracticesWe have trouble in understanding the requirements that we do acquire from the customer

We often record requirements in a disorganized manner

We spend far too little time verifying what we do record

We allow change to control us, rather than establishing mechanisms to control change

Most importantly, we fail to establish a solid foundation for the system or software that the user wants built

8The Problems with our Requirements Practices (contd..)Many software developers argue thatBuilding software is so compelling that we want to jump right in (before having a clear understanding of what is needed)Things will become clear as we build the softwareProject stakeholders will be able to better understand what they need only after examining early iterations of the softwareThings change so rapidly that requirements engineering is a waste of timeThe bottom line is producing a working program and that all else is secondaryAll of these arguments contain some truth, especially for small projects that take less than one month to completeHowever, as software grows in size and complexity, these arguments begin to break down and can lead to a failed software project 9A Solution: Requirements EngineeringBegins during the communication activity and continues into the modeling activity

Builds a bridge from the system requirements into software design and construction

Allows the requirements engineer to examinethe context of the software work to be performedthe specific needs that design and construction must addressthe priorities that guide the order in which work is to be completedthe information, function, and behavior that will have a profound impact on the resultant design

10A Bridge to Design and ConstructionUnderstanding the requirements of a problem is among the most difficult tasks that face a software engineer.

Requirements engineering establishes a solid base for design and construction. Without it, the resulting software has a high probability of not meeting customers needs.

Requirement engineering builds a bridge to design and construction. But where does the bridge originate?Begins at the feet of the project stakeholders, where business need is defined, user scenarios are described, functions and features are delineated and project constraints are identified.

Requirements Engineering TasksRequirements engineering provides the appropriate mechanism for Understanding what the customer wants,Analyzing need,Assessing feasibility,Negotiating a reasonable solution,Specifying the solution unambiguously,Validating the specification and Managing the requirements as they are transformed into an operational system.

Seven distinct tasks: Inception, Elicitation, Elaboration, Negotiation, Specification, Validation, Requirements Management

1213RequirementsManagementValidationInceptionElicitationElaborationNegotiationSpecification

Inception TaskDuring inception, the requirements engineer asks a set of questions to establishA basic understanding of the problemThe people who want a solutionThe nature of the solution that is desiredThe effectiveness of preliminary communication and collaboration between the customer and the developer

Through these questions, the requirements engineer needs to Identify the stakeholdersRecognize multiple viewpointsWork toward collaborationBreak the ice and initiate the communication

14The First Set of QuestionsWho is behind the request for this work?Who will use the solution?What will be the economic benefit of a successful solution?Is there another source for the solution that you need?15These questions focus on the customer, other stakeholders, the overall goals, and the benefits The Next Set of QuestionsHow would you characterize "good" output that would be generated by a successful solution?What problem(s) will this solution address?Can you show me (or describe) the business environment in which the solution will be used?Will special performance issues or constraints affect the way the solution is approached?16These questions enable the requirements engineer to gain a better understanding of the problem and allow the customer to voice his or her perceptions about a solution The Final Set of QuestionsAre you the right person to answer these questions? Are your answers "official"?Are my questions relevant to the problem that you have?Am I asking too many questions?Can anyone else provide additional information?Should I be asking you anything else?17These questions focus on the effectiveness of the communication activity itself Elicitation TaskQuestions asked in a manner that no further doubt remains

Elicitation of requirements is difficult becauseProblems of scope in identifying the boundaries of the system or specifying too much technical detail rather than overall system objectivesProblems of understanding what is wanted, what the problem domain is, and what the computing environment can handle (Information that is believed to be "obvious" is often omitted)Problems of volatility because the requirements change over time

Elicitation may be accomplished through two activitiesCollaborative requirements gatheringQuality function deployment18Elaboration TaskDuring elaboration, the software engineer takes the information obtained during inception and elicitation and begins to expand and refine it

Elaboration focuses on developing a refined technical model of software functions, features, and constraints

It is an analysis modeling taskUse cases are developedDomain classes are identified along with their attributes and relationshipsState machine diagrams are used to capture the life on an object

The end result is an analysis model that defines the functional, informational, and behavioral domains of the problem 19Developing Use CasesStep One Define the set of actors that will be involved in the storyActors are people, devices, or other systems that use the system or product within the context of the function and behavior that is to be describedActors are anything that communicate with the system or product and that are external to the system itselfStep Two Develop use cases, where each one answers a set of questions

20Questions Commonly Answered by a Use CaseWho is the primary actor(s), the secondary actor(s)?What are the actors goals?What preconditions should exist before the scenario begins?What main tasks or functions are performed by the actor?What exceptions might be considered as the scenario is described?What variations in the actors interaction are possible?What system information will the actor acquire, produce, or change?Will the actor have to inform the system about changes in the external environment?What information does the actor desire from the system?Does the actor wish to be informed about unexpected changes?21Elements of the Analysis ModelScenario-based elementsDescribe the system from the user's point of view using scenarios that are depicted in use cases and activity diagramsClass-based elementsIdentify the domain classes for the objects manipulated by the actors, the attributes of these classes, and how they interact with one another; they utilize class diagrams to do thisBehavioral elementsUse state diagrams to represent the state of the system, the events that cause the system to change state, and the actions that are taken as a result of a particular event; can also be applied to each class in the systemFlow-oriented elementsUse data flow diagrams to show the input data that comes into a system, what functions are applied to that data to do transformations, and what resulting output data are produced

22Negotiation TaskDuring negotiation, the software engineer reconciles the conflicts between what the customer wants and what can be achieved given limited business resources

Requirements are ranked (i.e., prioritized) by the customers, users, and other stakeholders

Risks associated with each requirement are identified and analyzed

Rough guesses of development effort are made and used to assess the impact of each requirement on project cost and delivery time

Using an iterative approach, requirements are eliminated, combined and/or modified so that each party achieves some measure of satisfaction23The Art of NegotiationRecognize that it is not competitionMap out a strategyListen activelyFocus on the other partys interestsDont let it get personalBe creativeBe ready to commit24Specification TaskA specification is the final work product produced by the requirements engineerIt is normally in the form of a software requirements specificationIt serves as the foundation for subsequent software engineering activitiesIt describes the function and performance of a computer-based system and the constraints that will govern its developmentIt formalizes the informational, functional, and behavioral requirements of the proposed software in both a graphical and textual format25Typical Contents of a Software Requirements SpecificationRequirementsRequired states and modesSoftware requirements grouped by capabilities (i.e., functions, objects)Software external interface requirementsSoftware internal interface requirementsSoftware internal data requirementsOther software requirements (safety, security, privacy, environment, hardware, software, communications, quality, personnel, training, logistics, etc.)Design and implementation constraintsQualification provisions to ensure each requirement has been metDemonstration, test, analysis, inspection, etc.Requirements traceabilityTrace back to the system or subsystem where each requirement applies26Validation TaskDuring validation, the work products produced as a result of requirements engineering are assessed for quality

The specification is examined to ensure thatall software requirements have been stated unambiguouslyinconsistencies, omissions, and errors have been detected and correctedthe work products conform to the standards established for the process, the project, and the product

The formal technical review serves as the primary requirements validation mechanismMembers include software engineers, customers, users, and other stakeholders

27Questions to ask when Validating RequirementsIs each requirement consistent with the overall objective for the system/product?Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?Is each requirement bounded and unambiguous?Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement?28Questions to ask when Validating Requirements (continued)Do any requirements conflict with other requirements?Is each requirement achievable in the technical environment that will house the system or product?Is each requirement testable, once implemented?Approaches: Demonstration, actual test, analysis, or inspectionDoes the requirements model properly reflect the information, function, and behavior of the system to be built?Has the requirements model been partitioned in a way that exposes progressively more detailed information about the system?29Requirements Management TaskDuring requirements management, the project team performs a set of activities to identify, control, and track requirements and changes to the requirements at any time as the project proceeds

Each requirement is assigned a unique identifier

The requirements are then placed into one or more traceability tables

These tables may be stored in a database that relate features, sources, dependencies, subsystems, and interfaces to the requirements

A requirements traceability table is also placed at the end of the software requirements specification30Requirements ManagementTraceability tablesFeatures traceability table- shows how requirements relate to important customer observable system/product featuresSource traceability table- identifies the source of each requirement.Dependency traceability table- indicates how requirements are related to one anotherSubsystem traceability table- categories requirements by the subsystem that they governInterface traceability table- shows how requirements relate to both internal and external system interfaces