Transparency Masters for Software Engineering: A Practitioner's Approach, 4/e

Requirements Engineering

1NeedA customer walks into your office, sits down, looks you straight in the eye 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. And this is said very late in your projects.Requirement engineering helps you to better understand the problems.2Requirements Engineering TasksInceptionEstablish a basic understanding of the problem and the nature of the solution. ElicitationDraw out the requirements from stakeholders.ElaborationCreate an analysis model that represents information, functional, and behavioral aspects of the requirements.NegotiationAgree on a deliverable system that is realistic for developers and customers.SpecificationDescribe the requirements formally or informally.ValidationReview the requirement specification for errors, ambiguities, omissions, and conflicts. Requirements managementManage changing requirements.

3InceptionAsk context-free questionsWho is behind the request for this work?Who will use the solution (product/system)?What will be the economic benefits?

How would you characterize good output from the system?What problems does this solution address?What environment will the product be used in?

Are you the right person to answer these questions?Are these question relevant?Can anyone else provide additional information?Should I be asking you anything else?4Eliciting RequirementsWhy is it so difficult to clearly understand what the customer wants?ScopeThe boundary of the system is ill-defined.Customers/users specify unnecessary technical detail that may confuse rather than clarify objectives.UnderstandingCustomers are not completely sure of what is needed.Customers have a poor understanding of the capabilities and limitations of the computing environment.Customers dont have a full understanding of their problem domain.Customers have trouble communicating needs to the system engineer.Customers omit detail that is believed to be obvious.Customers specify requirements that conflict with other requirements.Customers specify requirements that are ambiguous or untestable.VolatilityRequirements change over time.

5Collaborative Requirements GatheringMeetings are attended by all interested stakeholders.Rules established for preparation and participation.Agenda should be formal enough to cover all important points, but informal enough to encourage the free flow of ideas.A facilitator controls the meeting.A definition mechanism (blackboard, flip charts, etc.) is used.During the meeting:The problem is identified.Elements of the solution are proposed.Different approaches are negotiated.A preliminary set of solution requirements are obtained.The atmosphere is collaborative and non-threatening. 6Elicitation Work ProductsStatement of need and feasibility.Statement of scope.List of participants in requirements elicitation.Description of the systems technical environment.List of requirements and associated domain constraints.List of usage scenarios.Any prototypes developed to refine requirements.7Use-CasesA use-case scenario is a story about how someone or something external to the software (known as an actor) interacts with the system.Each scenario answers the following questions:Who is the primary actor, the secondary actor(s)?What are the actors goals?What preconditions should exist before the story begins?What main tasks or functions are performed by the actor?What exceptions might be considered as the story 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?8Elements of the Analysis ModelScenario-based elementsUse-caseHow external actors interact with the system (use-case diagrams; detailed templates)FunctionalHow software functions are processed in the system (flow charts; activity diagrams)Class-based elementsThe various system objects (obtained from scenarios) including their attributes and functions (class diagram)Behavioral elementsHow the system behaves in response to different events (state diagram)Flow-oriented elementsHow information is transformed as if flows through the system (data flow diagram)9Use-Case Diagram10

Activity Diagram for RE11

Class Diagram12

State Diagram13

Negotiating RequirementsIdentify the key stakeholdersThese are the people who will be involved in the negotiationDetermine each of the stakeholders win conditionsWin conditions are not always obviousNegotiateWork toward a set of requirements that lead to win-win14Specifying RequirementsCan be Written documentA set of graphical modelsA collection of usage scenariosA prototypeOr any combination of these

15Validating RequirementsIs each requirement consistent with the objective of the system?Have all requirements been specified at the proper level of abstraction? Is the requirement really necessary?Is each requirement bounded and unambiguous?Does each requirement have attribution? Do any requirements conflict with other requirements?Is each requirement achievable in the systems technical environment?Is each requirement testable, once implemented?Does the model reflect the systems information, function and behavior?Has the model been appropriately partitioned?Have appropriate requirements patterns been used?16Requirement ManagementSet of activities to help the project team to Track, Identify and Control the changes in the requirement.

17

Building an Analysis Model1818OverviewActivityActionTaskCommunicationInceptionRequirements Engineering

Req. ElicitationReq. Analysis & NegotiationReq. SpecificationReq. Verification and ValidationReq. Management

PlanningModelingAnalysis ModelingDesign ModelingContext ModelingTechnical ModelingConstructionDeployment19Requirements/Analysis ModelA graphical representations of business processes, the problems to be solved, and the new proposed product (software).Objectives:To describe software requirements.To establish a basis for the creation of a software design.To define a set of requirements that can be validated once the software is built.Bridges the gap between a software specification and a software design.20Software specification

Design ModelAnalysis ModelRules of ThumbSuggested by Arlow and Neustadt :The model should focus on requirements that are visible within the problem or business domain. The level of abstraction should be relatively high. Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function and behavior of the system.Delay consideration of infrastructure and other non-functional models until design. Minimize coupling throughout the system. Be sure that the analysis model provides value to all stakeholders. Keep the model as simple as possible especially if extra diagrams do not provide new information.21Requirements Modeling PrinciplesPrinciple #1. The information domain of a problem must be represented and understood.Principle #2. The functions that the software performs must be defined. Principle #3. The behavior of the software (as a consequence of external events) must be represented.Principle #4. The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion.Principle #5. The analysis task should move from essential information toward implementation detail.

22Domain AnalysisAccording to Donald : Software domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain . . .[Object-oriented domain analysis is] the identification, analysis, and specification of common, reusable capabilities within a specific application domain, in terms of common objects, classes, subassemblies, and frameworks . . .

23Approaches for Technical ModelingObject-oriented Analysismodel objects, classes, and the relationships and behavior associated with them.The industry standard for the OO modeling is known as Unified Modelling Language (UML) specification and the current available version is 2.2 (OMG, 2009).E.g.: use-case diagrams, activity diagrams (swim-lane diagram), sequence diagram, class diagram, state diagram, and etc. Structured AnalysisConsiders data and the processes that transform the data as separate entities.Includes data models, data flow models and behavioral modelsE.g.: ERD, DFD, state machine model

2424

Analysis Model25Elements of the analysis model25Object-oriented Analysis(Scenario-Based Modeling)Write Use-CasesDevelop Activity DiagramDevelop Swim lane Diagram2626Use-case Diagram27

Use-case diagram for surveillance function

Activity diagram for Access camera surveillancedisplay camera views function2828

Swimlane diagram2929Flow-Oriented Modeling (Structured Analysis)Guidelines Depict the system as single bubble in level 0.Carefully note primary input and output.Label all elements with meaningful names.Maintain information conformity between levels.Refine one bubble at a time.30SafeHome Case StudyAssume that a team working for a consumer products company has provided following product description: Our research indicates that the market for home security systems is growing at a rate of 40 percent per year. We would like to enter this market by building a microprocessor-based home security system that would protect against and/or recognize a variety of undesirable "situations" such as illegal entry, fire, flooding, and others. The product, tentatively called SafeHome, will use appropriate sensors to detect each situation, can be programmed by the homeowner, and will automatically telephone a monitoring agency when a situation is detected.31

Data Flow Diagram32Context-level DFD for SafeHome security function32

3333

Level 2 DFD that refines the monitor sensors process 3434

Control Flow Diagram35State diagram for SafeHome security function35Class-Based Modeling3636Identifying Analysis ClassesCommon technique for identifying classes in the context of a software problem is to perform a grammatical parse on the processing narrative for the system. All nouns become potential objects.3737Identifying Analysis ClassesE.g.External entitiesThingsOccurrencesEventsRolesOrganizational unitsPlacesStructures.3838Class Selection CharacteristicsRetained informationIf information about it must be remembered so that the system can function.Needed servicesOperations that can change the value of its attributesMultiple attributesDuring requirements analysis, the focus should be on "major" informationAn object with a single attribute may be useful during design but is probably better represented as an attribute of another object during the analysis activity.3939Class Selection CharacteristicsCommon attributesAttributes should apply to all occurrences of the object.Common operationsOperations should apply to all occurrences of the object.Essential requirementsExternal entities that appear in the problem space and produce or consume information that is essential to the operation of any solution for the system will almost always be defined as class in the requirements model.40Identifying ClassesPotential classClassificationAccept / Rejecthomeownerrole; external entityreject: 1, 2 failsensorexternal entityacceptcontrol panelexternal entityacceptinstallationoccurrencereject(security) systemthingacceptnumber, typenot objects, attributesreject: 3 failsmaster passwordthingreject: 3 failstelephone numberthingreject: 3 failssensor eventoccurrenceacceptaudible alarmexternal entityaccept: 1 failsmonitoring serviceorganizational unit; eereject: 1, 2 fail41Class Diagram42

Class diagram for the system class42Class diagram for FloorPlan43

43Class ResponsibilitiesGuidelines for allocating responsibilities to classes:System intelligence should be evenly distributedEach responsibility should be stated as generally as possibleAbstraction PolymorphismInformation and the behavior related to it should reside within the same class.EncapsulationInformation about one thing should be localized with a single class, not distributed across multiple classesResponsibilities should be shared among related classes, when appropriate.4444Class CollaborationsClasses fulfill their responsibilities in one of two ways:A class can use its own operations to manipulate its own attributes, thereby fulfilling a particular responsibility, ora class can collaborate with other classesRelationships between classes:is-part-of used when classes are part of an aggregate class.has-knowledge-of used when one class must acquire information from another class.depends-on used in all other cases.45Class Diagrams46

Top: MultiplicityBottom: Dependencies46CRC Modeling47Class responsibility collaborator (CRC) modeling provides a simple means for identifying and organizing the classes that are relevant to system or product requirements.CRC Modeling48

A CRC model index card for FloorPlan class48Behavioral Modeling4949Identifying EventsA use-case is examined for points of information exchange.The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password in incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action.50State Diagram51State diagram for the ControlPanel class

51Sequence Diagram52

Sequence diagram (partial) for the SafeHome security function52