2 Contents 4.1 The Requirements Process 4.2 Requirements Elicitation Types of RequirementsCharacteristic of RequirementsModelling Notations4.6 Requirements and Specification Languages4.7 Prototyping Requirements4.8 Requirements Documentation4.9 Validation and Verification4.10 Measuring Requirements4.11 Choosing a Specification TechniqueInformation System Example4.13 Real Time Example
3 Chapter 4 Objectives Eliciting requirements from the customers Modelling requirementsReviewing requirements to ensure their qualityDocumenting requirements for use by the design and test teams
4 4.1 The Requirements Process A requirement is an expression of desired behaviourA requirement deals withobjects or entitiesthe state they can be infunctions that are performed to change states or object characteristicsRequirements focus on the customer needs, not on the solution or implementationRequirements designate what behaviour the customer wants it, without saying how that behaviour will be realized
5 4. 1 The Requirements Process Sidebar 4 4.1 The Requirements Process Sidebar 4.1 Why Are Requirements Important?Top factors that caused project to failIncomplete requirementsLack of user involvementUnrealistic expectationsLack of executive supportChanging requirements and specificationsLack of planningSystem no longer neededRequirements error can be expensive if not detected earlySlayt: From highest to lowest.. 13% to 7.5%
6 4.1 The Requirements Process Process for Capturing Requirements Performed by the req. analyst or system analystThe final outcome is a Software Requirements Specification (SRS) documentSpecification: We decide which parts of the required behavior will be implemented.
7 4.1 The Requirements Process Sidebar 4.2 Agile Requirements Modelling If requirements are tightly coupled and complex, we may be better off with a “heavy” process that emphasizes up-front modellingIf the requirements are uncertain, agile methods are an alternative approachAgile methods gather and implement the requirements in incrementsExtreme Programming (XP) is an agile processThe requirements are defined as we build the systemNo planning or designing for possible future requirementsEncodes the requirements as test cases that eventually implementation must passSlayt: How use of agile methods affects the requirements…If requirements… sonrasi….In a heavy process, developers put off coding until the requirements have been modeled and analyzed. (safety-critical systems)Encodes… Instead of having traditional requirements documentation.
8 4.2 Requirements Elicitation Customers do not always understand what their needs and problems areIt is important to discuss the requirements with everyone who has a stake in the systemCome up with agreement on what the requirements areIf we can not agree on what the requirements are, then the project is doomed to fail
9 4.2 Requirements Elicitation Stakeholders Clients: pay for the software to be developedCustomers: buy the software after it is developedUsers: use the systemDomain experts: familiar with the problem that the software must automateMarket Researchers: conduct surveys to determine future trends and potential customersLawyers or auditors: familiar with government, safety, or legal requirementsSoftware engineers or other technology experts
10 4. 2 Requirements Elicitation Sidebar 4 4.2 Requirements Elicitation Sidebar 4.3 Using Viewpoints to Manage InconsistencyNo need to resolve inconsistencies early in the requirements process (Easterbrook and Nuseibah, 1996)Authors proposed Stakeholders' views documented and maintained as separate Viewpoints through the software development processThe requirements analyst defines consistency rules that should apply between ViewpointsThe Viewpoints are analyzed to see if they conform to the consistency requirementsInconsistencies are highlighted but not addressed until there is sufficient information to make informed decision
11 4.2 Requirements Elicitation Means of Eliciting Requirements Interviewing stake holdersReviewing available documentationsObserving the current system (if one exists)Apprenticing with users to learn about user's task in more detailsInterviewing user or stakeholders in groupsUsing domain specific strategies, such as Joint Application Design to consider specific type of requirementsBrainstorming with current and potential users
12 4.2 Requirements Elicitation Means of Eliciting Requirements (continued) The Volere requirements process model suggests some additional sources for requirementsSekil hakkinda konus.
13 4.3 Types of RequirementsFunctional requirement: describes required behaviour in terms of required activitiesQuality requirement or non-functional requirement: describes some quality characteristic that the software must possesDesign constraint: a design decision such as choice of platform or interface componentsProcess constraint: a restriction on the techniques or resources that can be used to build the systemFunctional… Ornek: For a payroll system, the functional requirements state how often paychecks are issued, what input is necessary for a paycheck to be printed, and what causes the removal of an employee from the payroll list.Quality… Such as fast response time, ease of useProcess. Ornek: Customers may insist that we use agile methods, so that they can use early version of the system…
14 4.3 Types of Requirements Resolving Conflicts Different stakeholder has different set of requirementspotential conflicting ideasNeed to prioritize requirementsPrioritization might separate requirements into three categoriesessential: absolutely must be metdesirable: highly desirable but not necessaryoptional: possible but could be eliminatedAlttaki ucunu acikla… Kredi karti ornegi: Aylik borcu cikarmasi essential, Separate purchase type necessary, bazi yerleri kirmizi bazi yerleri siyah ile cizmesi optionalPrioritization helps in resolving conflicts.
15 4.3 Types of Requirements Two Kinds of Requirements Documents Requirements definition: a complete listing of everything the customer wants to achieveDescribing the entities in the environment where the system will be installedRequirements specification: restates the requirements as a specification of how the proposed system shall behave
16 4.3 Types of Requirements Two Kinds of Requirements Documents (continued) Requirements defined anywhere within the environment's domain, including the system's interfaceSpecification restricted only to the intersection between environment and system domainSekil: Requirements vs. Specification
17 4.4 Characteristics of Requirements CorrectConsistentUnambiguousCompleteFeasibleRelevantTestableTraceableSlayt: These are the questions we should consider for desirable characteristics..Are the requirements correct? Both we and the customer should review the document.Are the requirements consistent? I.e one requirement say max of 10 user can use the system, and another one says 20?…………………… unambiguous?
18 4.5 Modelling NotationsIt is important to have standard notations for modelling, documenting, and communicating decisionsModelling helps us to understand requirements thoroughlyHoles in the models reveal unknown or ambiguous behaviourMultiple, conflicting outputs to the same input reveal inconsistencies in the requirements
19 4.5 Modelling Notations Entity-Relationship Diagrams A popular graphical notational paradigm for representing conceptual modelsHas three core constructsAn entity: depicted as a rectangle, represents a collection of real-world objects that have common properties and behavioursA relationship: depicted as an edge between two entities, with diamond in the middle of the edge specifying the type of relationshipAn attribute: an annotation on an entity that describes data or properties associated with the entity
20 4.5 Modeling Notations Entity-Relationship Diagrams (continued) Entity diagram of turnstile problemDiamond: Type of the relationship
21 4.5 Modelling Notations Entity-Relationship Diagrams (continued) ER diagrams are popular becausethey provide an overview of the problem to be addressedthe view is relatively stable when changes are made to the problem's requirementsER diagram is likely to be used to model a problem early in the requirements processThe view… a change in the requirements most likely to change in how one or more entities behave than to be a change in the set of participating entities.
22 4.5 Modelling Notations ER Diagrams Example: UML Class Diagram UML (Unified Modelling Language) is a collection of notations used to document software specifications and designsIt represents a system in terms ofobjects: organized in classes that have an inheritance hierarchymethods: actions on the object's variablesThe class diagram is the flagship model in any UML specificationA sophisticated ER diagram relating the classes (entities) in the specification
23 4.5 Modelling Notations UML Class Diagram of Library Problem Fine rate and reserve loan period is class scope attribute, shared by all the entities.Black diamond: Composition
24 4.5 Modelling Notations UML Class Diagram (continued) Attributes and operations are associated with the class rather than instances of the classA class-scope attribute represented as an underlined attribute, is a data value that is shared by all instances of the classA class-scope operation written as underlined operation, is an operation performed by the abstract class rather than by class instancesAn association, marked as a line between two classes, indicates a relationship between classes' entities
25 4.5 Modelling Notations UML Class Diagram (continued) Aggregate association is an association that represents interaction, or events that involve objects in the associated (marked with white diamond)“has-a” relationshipComposition association is a special type of aggregation, in which instances of the compound class are physically constructed from instances of component classes (marked with black diamond)Aggregate… one class is a property or element of the other class.
26 4.5 Modelling Notations Event Traces A graphical description of a sequence of events that are exchanged between real-world entitiesEach graph depicts a single trace, representing one of several possible behavioursTraces have a semantic that is relatively precise, simple and easy to understandSlayt: ER diagram’s show which entities are related, but not how the entities are to behave.
27 4.5 Modeling Notations Event Traces (continued) Graphical representation of two traces for the turnstile problemtrace on the left represents typical behaviortrace on the right shows exceptional behaviorVertical line: the timeline of distinct entity, whose name appear at the top of the lineHorizontal line: an event or interaction between the two entities bounding the lineTime progresses from top to bottom
28 4.5 Modelling Notations Event Traces Example: Message Sequence Chart An enhanced event-trace notation, with facilities for creating and destroying entities, specifying actions and timers, and composing traces
29 4.5 Modeling Notations Message Sequence Chart (continued) Message sequence chart for library loan transactionVertical line represents a participating entityA message is depicted as an arrow from the sending entity to the receiving entityActions are specified as labelled rectangles positioned on an entity's execution lineConditions are important states in an entity's evolution, represented as labeled hexagon
30 4.5 Modelling Notations State Machines A graphical description of all dialog between the system and its environmentUseful bothfor specifying dynamic behaviour andfor describing how behaviour should change in response to the history of events that have already occurred
31 4.5 Modelling Notations State Machines (continued) Finite state machine model of the turnstile problemNode (state) represents a stable set of conditions that exists between event occurrencesEdge (transition) represents a change in behaviour or condition due to the occurrence of an event
32 4.5 Modelling Notations State Machines (continued) A path: starting from the machine's initial state and following transitions from state to stateRepresents a trace of observable events in the environmentDeterministic state machine: for every state and event there is a unique response
33 4.5 Modelling Notations State Machines Example: UML State chart Diagrams A UML state chart diagram depicts the dynamic behaviour of the objects in a UML classUML class diagram has no information about how the entities behave, how the behaviours changeA UML model is a collection of concurrently executing state chartsUML state chart diagram have a rich syntax, including state hierarchy, concurrency, and inter-machine communication
34 4.5 Modeling Notations UML Statechart Diagrams (continued) The UML statechart diagram for the Publication class from the Library class modelState hierarchy is used to unclutter diagrams by collecting into superstate those states with common transitionsA superstate can actually comprise multiple concurrent sub-machines, separated by dashed lineThe sub-machines are said to operate concurrently
35 4.5 Modeling Notations UML Statechart Diagrams (continued) An equivalent statechart for Publication class that does not make use of state hierarchy or concurrencycomparatively messy and repetitive
36 4.5 Modeling Notations UML Statechart Diagrams (continued) The UML statechart diagram for Loan association class illustrates how states can be annotated with local variables, actions and activitiesOrnek: variable num renews is increment every time state “item on loan” is entered.When a transitions, including a looping transition like the one triggered by renew, executes, the order in which actions are applied is as follows.1- the exit actions of the transition’s source state are applied.2-followed by the transition’s own actions3-followed by the entry actions and activities of the new state.
37 4.5 Modelling Notations State Machines: Ways of Thinking about State The hardest part of constructing a state- machine model is deciding how to decompose an object’s behavior into states. Some ways of thinking about states includeEquivalence classes of possible future behaviourPeriods of time between consecutive eventNamed control points in an object's evolutionPartition of an object's behaviour
38 4.5 Modelling Notations State Machines Example: Petri Nets A form or state-transition notation that is used to model concurrent activities and their interaction
39 4.5 Modeling Notations Petri Nets (continued) Petri net of book loanCircles (places) represent activities or conditionsBars represents transitionsArcs connect a transition with its input places and its output placesThe places are populated with tokens, which act as enabling conditions for the transitionsEach arc can be assigned a weight that specifies how many tokens are removed from arc's input place, when the transition fires
40 4.5 Modeling Notations Petri Nets (continued) A high level Petri net specification for the library problem
41 4.5 Modelling Notations Data-Flow Diagrams ER diagram, event trace, state machines depict only lower-level behavioursA data-flow diagram (DFD) models functionality and the flow of data from one function to anotherER… This modular structures makes it harder to see a model’s high level functionality…
42 4.5 Modeling Notations Data-Flow Diagrams (continued) A high-level data-flow diagram for the library problemA bubble represents a processAn arrow represents data flowA data store: a formal repository or database of informationRectangles represent actors: entities that provide input data or receive the output result
43 4.5 Modelling Notations Data-Flow Diagrams (continued) Advantage:Provides an intuitive model of a proposed system's high-level functionality and of the data dependencies among various processesDisadvantage:Can be aggravatingly ambiguous to a software developer who is less familiar with the problem being modelledSlayt Sonu: Borrow’a uc input giriyor. Ucunun de sonucu beklenmeli mesela? Bunun hakkinda bilgi vermiyor..
44 4.5 Modelling Notations Data-Flow Diagrams Example: Use Cases Use cases do not model all the tasks, instead they are used to specify user views of essential system behaviour
45 4.5 Modeling Notations Use Cases (continued) Library use cases including borrowing a book, returning a borrowed book, and paying a library fineA large box: system boundaryStick figures outside the box: actors, both human and systemsEach oval inside the box: a use case that represents some major required functionality and its variantA line between an actor and use case: the actor participates in the use caseSubcases <<include>>A use case can also be appended with an extension subcase that adds functionality to the end of the use case.
46 4.5 Modelling Notations Functions and Relations Formal methods or approach: mathematically based specification and design techniquesFormal methods model requirements or software behaviour as a collection of mathematical functions or relationsFunctions specify the state of the system's execution, and outputA relation is used whenever an input value maps more than one output valueFunctional method is consistent and complete since it maps each input to a single output.
47 4.5 Modelling Notations Functions and Relations (continued) Example: representing turnstile problem using two functionsOne function to keep track of the stateOne function to specify the turnstile output
48 4.5 Modelling Notations Functions and Relations Example: Decision Tables It is a tabular representation of a functional specification that maps events and conditions to appropriate responses or actionThe specification is informal because the inputs (events and conditions) and outputs (actions) may be expressed in natural languageIf there is n input conditions, there are 2n possible combination of input conditionsCombinations map to the same set of result can be combined into a single column
49 4.5 Modeling Notations Decision Tables (continued) Decision table for library functions borrow, return, reserve, and unreserveGrafik: T: input condition is true.F: FalseX: means row’s action should be performed whenever its corresponding input conditions hold.
50 4.5 Modelling Notations Functions and Relations Example: Parnas Tables Tabular representations of mathematical functions or relationsThe column and row headers are predicates used to specify casesThe internal table entries store the possible function resultsAn entry “X” either could be invalid under the specified conditions or the combination of conditions is infeasibleCalc due date (patron, publication, event, Today) =
51 4.5 Modelling Notations Logic An operational notation is a notation used to describe a problem or a proposed software solution in terms of situational behaviourThe result is a model of case-based behaviourExamples: what the next state or system should beA descriptive notation is a notation that describes a problem or a proposed solution in terms of its properties or its variantExample: logic
52 4.5 Modelling Notations Logic (continued) A logic consists of a language for expressing properties and a set of inference rules for deriving new, consequent properties from the stated propertiesIn logic, a property specification represents only those values of the property's variables for which the property's expression evaluates to trueIt is first-order logic, comprising typed variables, constants, functions, and predicates
53 4.5 Modelling Notations Logic (continued) Consider the following variables of turnstile problem, with their initial valueThe first-order logic expressionsnum_coins > num_entries (num_coins > num_entries (barrier = unlocked) (barrier = locked ) ¬may_enter
54 4.5 Modelling Notations Logic (continued) Temporal logic introduces additional logical connectives for constraining how variables can change value over timeThe following connectives constrain future variable values, over a single execution□f Ξ f is true now and throughout the rest of execution⋄f Ξ f is true now or at some point in the execution○f Ξ f is true in the next point in the executionf W g = f is true until a point where g is true, but g may never be true
55 4.5 Modelling Notations Logic Example: Object Constrain Language (OCL) A constrain language that is both mathematically precise and easy for non- mathematicians to read, write, and understandDesigned for expressing constrains on object models, and expressing queries on object type
56 4.5 Modelling Notations Library classes annotated with OCL properties Sekil: No patron’s fines may have a negative value. The topmost constraint specified that call numbers are unique. In other words, for any two publication, p1 and p2, returned by allinstances, if p1 and p2 are not the same publication, then they have different call numbers. The third one attached to the method borrow, expresses the operation’s pre and post conditions.
57 Combines multiple notation paradigms 4.6 Requirements and Specification Languages Unified Modeling Language (UML)Combines multiple notation paradigmsSix graphical modelling notations, and the OCL constrain language, includingUse-case diagram (a high-level DFD)Class diagram (an ER diagram)Sequence diagram (an event trace)Collaboration diagram (an event trace)Statechart diagram (a state-machine model)OCL properties (logic)
58 4.6 Requirements and Specification Languages Specification and Description Language (SDL) Standardized by the International Telecommunication UnionSpecifies the behavior of real-time, concurrent, distributed processes that communicate with each other via unbounded message queuesComprisesSDL system diagram (a DFD)SDL block diagram (a DFD)SDL process diagram (a state-machine model)SDL data type (algebraic specification)Often accompanied by a set of Message Sequence Chart (MSC)
59 4.6 Requirements and Specification Languages SDL System Diagram The top-level blocks of the specification and communication channels that connect the blocksChannels are directional and are labelled with the type of signalsMessage is asynchronous
60 4.6 Requirements and Specification Languages SDL Block Diagram SDL block diagram Models a lower-level collection of blocks and the message-delaying channels that interconnect themFigure depicts a collection of lowest-level processes that communicate via signal routesSignal routes pass messages synchronously
61 4.6 Requirements and Specification Languages SDL Process Diagram It is a state-machine whose transitions are sequences of language constructs (input, decisions, tasks, outputs) that start and end at state constructs
62 4.6 Requirements and Specification Languages Software Cost Reduction (SCR) Collection of techniques that were designed to encourage software developers to employ good software-engineering design principlesModels software requirements as a mathematical function, REQ, that maps monitored variables to controlled variablesmonitored variables: environmental variables that are sensed by the systemcontrolled variables: environmental variables that are set by the systemThe function REQ is decomposed into a collection of tabular functions
63 4.6 Requirements and Specification Languages SCR (continued) REQ is the result of composing the tabular functions into network (a DFD) as shown in the picture.Edges reflect the data dependencies among the functionsExecution steps start with a change in the value of one monitored variable, then propagate through the network, in a single synchronised stepConditionModeonoffWarning’ =Temp 175Temp < 175Heat, MaintainXTrueOffABCDFE
64 Some techniques include notations 4.6 Requirements and Specification Languages Other Features of Requirement NotationsSome techniques include notationsfor the degree of uncertainty or risk with each requirementfor tracing requirements to other system documents such as design or code, or to other systems, such as when requirements are reusedMost specification techniques have been automated to some degree
65 4.7 Prototyping Requirements Building a Prototype To elicit the details of proposed systemTo solicit feedback from potential users aboutwhat aspects they would like to see improvewhich features are not so usefulwhat functionality is missingDetermine whether the customer's problem has a feasible solutionAssist in exploring options for optimizing quality requirements
66 4.7 Prototyping Requirements Prototyping Example Prototype for building a tool to track how much a user exercises each dayGraphical representation of first prototype, in which the user must type the day, month and yearSlayt: The tool’s user interface is important, because the users may not be familiar with computers.
67 4.7 Prototyping Requirements Prototyping Example (continued) Second prototype shows a more interesting and sophisticated interface involving a calendarUser uses a mouse to select the month and yearThe system displays the chart for that month, and the user selects the appropriate date in the chart
68 4.7 Prototyping Requirements Prototyping Example (continued) Third prototype shows that instead of calendar, the user is presented with three slide barsUser uses the mouse to slide each bar left or rightThe box at the bottom of the screen changes to show the selected day, month, and year
69 4.7 Prototyping Requirements Approaches to Prototyping Throwaway approachDeveloped to learn more about a problem or a proposed solution, and that is never intended to be part of the delivered softwareAllow us to write “quick-and-dirty”Evolutionary approachDeveloped not only to help us answer questions but also to be incorporated into the final productPrototype has to eventually exhibit the quality requirements of the final product, and these qualities cannot be retrofittedBoth techniques are sometimes called rapid prototypingAllow us… poorly structured, inefficient, with no error checkingBoth… becase they involve building software in order to answer questions about the requirements.
70 4.7 Prototyping Requirements Prototyping vs. Modeling Good for answering questions about the user interfacesModelingQuickly answer questions about constraints on the order in which events should occur, or about the synchronization of activities
71 4.8 Requirements Documentation Requirement Definition: Steps Documenting Process Outline the general purpose and scope of the system, including relevant benefits, objectives, and goalsDescribe the background and the rationale behind proposal for new systemDescribe the essential characteristics of an acceptable solutionDescribe the environment in which the system will operateOutline a description of the proposal, if the customer has a proposal for solving the problemList any assumptions we make about how the environment behaves1-List any terms, glossary as well.2- For example, if the system is to replace an existing approach, we need to explain why the existing approach is unsatisfactory.3- Brief description at the use case level. It also includes quality requirements, such as timing, accuracy, and responses to failures.4- which includes hardware and software information.
72 4.8 Requirements Documentation Requirements Specification: Steps Documenting Process Describe all inputs and outputs in detail, includingthe sources of inputsthe destinations of outputs,the value rangesdata format of inputs and output datadata protocolswindow formats and organizationstiming constraintRestate the required functionality in terms of the interfaces' inputs and outputsDevise fit criteria for each of the customer's quality requirements, so that we can conclusively demonstrate whether our system meets these quality requirementsRestate… You may use functional notation or data-flow diagrams to map inputs to outputs. State Machines or event-traces to illustrate exact sequences… and so on.
73 4.8 Requirements Documentation Sidebar 4.6 Level of Specification Survey shows that one of the problems with requirement specifications was the uneven level of specificationDifferent writing stylesDifference in experienceDifferent formatsOver-specifying requirementsUnder-specifying requirementsRecommendations to reduce unevennessWrite each clause so that it contains only one requirementAvoid having one requirement refer to another requirementCollect similar requirements togetherKendi proje dokumanlarindan soz et.
74 4.8 Requirements Documentation IEEE Standard for SRS Organized by Objects Intodruction to the Document1.1 Purpose of the Product1.2 Scope of the Product1.3 Acronyms, Abbreviations, Definitions1.4 References1.5 Outline of the rest of the SRSGeneral Description of Product2.1 Context of Product2.2 Product Functions2.3 User Characteristics2.4 Constraints2.5 Assumptions and DependenciesSpecific Requirements3.1 External Interface RequirementsUser InterfacesHardware InterfacesSoftware InterfacesCommunications Interfaces3.2 Functional RequirementsClass 1Class 2…3.3 Performance Requirements3.4 Design Constraints3.5 Quality Requirements3.6 Other RequirementsAppendices
75 4.8 Requirements Documentation Process Management and Requirements Traceability Process management is a set of procedures that trackthe requirements that define what the system should dothe design modules that are generated from the requirementthe program code that implements the designthe tests that verify the functionality of the systemthe documents that describe the systemIt provides the threads that tie the system parts together
76 4.8 Requirements Documentation Development Activities Horizontal threads show the coordination between development activitiesResim: In particular, during the requirements activities, we are concerned about establishing a correspondence between elements of the requirements definition and those of the requirements specification, so that the customer’s view is tied to the developer’s view in an organized, traceable way.
77 4.9 Validation and Verification In requirements validation, we check that our requirements definition accurately reflects the customer's needsIn verification, we check that one document or artifact conforms to anotherVerification ensures that we build the system right, whereas validation ensures that we build the right system
78 4.9 Validation and Verification List of techniques to validate requirements Validation can be as simple as reading the document and reporting errors.Alternatively we can hold a walkthrough,Ornek: bir kisi butun uyelere presentation yapiyor ve sonra onlarin feedbackini bekliyor…Soru: Hangi durumlarda daha yardimci olur? Cok stakeholder varsa hepsinin dokumani okumasi beklenmiyorsaFormal inspections… reviewers take on specific roles (presenter, moderator) and follow prescribed rules (when to meet, how to examine requirements, etc…)
79 4.9 Validation and Verification Requirements Review Review the stated goals and objectives of the systemCompare the requirements with the goals and objectivesReview the environment in which the system is to operateReview the information flow and proposed functionsAssess and document the risk, discuss and compare alternativesTesting the system: how the requirements will be revalidated as the requirements grow and change
80 4. 9 Validation and Verification Sidebar 4 4.9 Validation and Verification Sidebar 4.8 Number of Requirements FaultsBasili and Perricone report48% of the faults observed in a medium-scale software project were attribute to “incorrect or misinterpreted functional specification or requirements”Beizer attributes 8.12% of the faults in his samples to problems in functional requirements
81 4.9 Validation and Verification Verification Check that the requirements-specification document corresponds to the requirements- definitionMake sure that if we implement a system that meets the specification, then the system will satisfy the customer's requirementsEnsure that each requirement in the definition document is traceable to the specification
82 4.10 Measuring Requirements Measurements focus on three areasproductprocessresourcesNumber of requirements can give us a sense of the size of the developed systemNumber of changes to requirementsMany changes indicate some instability or uncertainty in our understanding of the systemRequirement-size and change measurements should be recorded by requirements typeSonuncu: Soru: Why we should record such category-based metrics?This tells us whether change or uncertainty in the requirements is product wide or rests solely with certain kinds of requirements, such as user-interface or database requirements.
83 4.10 Measuring Requirements Rating Scheme on Scale from 1 to 5 You understand this requirement completely, have designed systems from similar requirements, and have no trouble developing a design from this requirementSome elements of this requirement are new, but they are not radically different from requirements that have been successfully designed in the pastSome elements of this requirement are very different from requirements in the past, but you understand the requirement and can develop a good design from itYou cannot understand some parts of this requirement, and are not sure that you can develop a good designYou do not understand this requirement at all, and can not develop a designSlayt : We may ask the designers to rate each requirement on a scale from 1 to 5.
84 4.10 Measuring Requirements Testers/Designers Profiles Figure (a) shows profiles with mostly 1s and 2sThe requirements are in good shapeFigure (b) shows profiles with mostly 4s and 5sThe requirements should be revisedSlayt: We can create similar rating scheme that asks testers how well they understand each requirement.
85 4.11 Choosing a Specification Technique Criteria for Evaluating Specification Methods ApplicabilityImplementabilityTestability/SimulationCheckabilityMaintainabilityModularityVariabilityRun time safetyTools maturityLoosenessLearning curveTechnique maturityApplicability: Can the technique describe real-world problems and solutions in a natural and realistic way?Implementability: Can the specification be translated easily into an implementation?Testability: Can the specification be used to test the implementation?Checkability: Are the specifications readable by non-developers, such as the customer?Maintability: Will the specification be useful in making changes to the system?Modularity: Does the method allow a large specification to be composed into smaller parts that are easier to write and to understand?…Tools Maturity: If the specification technique has tool support, are the tools of high quality?Looseness: Can the specification be incomplete?Learning Curve: Can a new user learn quickly the techniques, concepts, syntax…?Technique Maturity: Has the technique been certified and standardized?
86 4.11 Choosing a Specification Technique Steps Determine which of the criteria are especially importantEvaluate each of the candidate techniques with respect to the criteriaChoose a specification technique that best supports the criteria that are most important to the problem
87 Important of Specification Criteria During Reactive-System Life Cyle R=Requirements, D=Design, I=Implementation, T=Testing, M=Maintenance, O=OtherSekil: Criteria’s effects on life-cycle activities.
88 4.12 Information System Example Picadilly Television System High-level diagram captures the essential functionalityShows nothing about the ways in which each of these use cases might succeed or failSlayt: We can draw a use-case diagram to represent the key uses of the system, showing the expected users and major functions that each user might initiate.Shows.. Sonrasi… for example a campaign request would fail if all of the commercial time was already sold.
89 4.12 Information System Example Picadilly Television System: Message Sequence Chart Slayt: Message Sequence chart depict typical scenarios within a use case. Request for a campaign involves, searching each relevant commercial break to find if any slot is available. Computing the Price, and reserving available commercial spots for the campaign.
90 4.12 Information System Example Picadilly Television System: Partial UML Class Diagram Slayt: Key entities and relationships are shown in this partial uml class diagram:
91 4.13 Real-Time ExampleAriane-5 failed due to requirement validation not done properlyRequirements validation could have played a crucial role in preventing the rocket's explosionTwo criteria that are especially important for specifying a system such as Ariane-5Testability/simulation and runtime safety
92 4.14 What This Chapter Means for You It is essential that the requirements definition and specification documents describe the problem, leaving solution selection to designerThere are variety of sources and means for eliciting requirementsThere are many different types of definition and specification techniquesThe specification techniques also differ in terms of their tool support, maturity, understandability, ease of use, and mathematical formalityRequirements questions can be answered using models or prototypesRequirements must be validated to ensure that they accurately reflect the customer's expectations