SE: CHAPTER 4 Capturing the Requirements

1. SE: CHAPTER 4Capturing the Requirements • Two types of requirements : functional and non-functional • Eliciting requirements from customers • Types of requirements • Notations and methods for capturing requirements • Ensuring requirements quality • Documenting requirements

2. 4.1 The Requirements Process • The nature of new a system • The new system may replace an existing system or way of doing things • The new system is an enhancement or extension of a current manual or automatic system • Frequently the new system is planned for doing things that have never been done before • A Requirement • Is a feature or a description of something the system is capable of doing in order to fulfill the system’s purpose

3. The Requirements Process • The process of capturing requirements • See Fig 4.1, p.136 • The process steps • First, we work with customers to elicit the requirements • By asking questions, demonstrating similar systems, or developing prototypes • Next, we capture the requirements in documents • So that we and our customers agree on what the system should do • Next, The requirements are re-written in a more formal or mathematical representation • So that the designer can transform the requirements into a good system design

4. The Requirements Process • The process of capturing requirements • The process steps • Next, a verification step ensures the requirements are complete, correct and consistent • Next, a validation step makes sure that we have described what the customer intends to see in the final product. • Requirements process is critical • See Sidebar 4.1, p.137 • The Top 8 factors that cause the failure of projects • Incomplete requirements and changing of requirements account for 13.1% + 8.7%

5. Requirements Elicitation • Use a variety of techniques • Examine what is already done in the old system or old ways ? • Work with users and customers to understand the problem to find a solution • Identify people, processes and resources involved and then document the relationships among them • Who and in which role people are involved in the system’s functionalities • Find out which data items are involved, where do they come from, how they are passed from one role to another, which processes transform them from one form or state to another • Ask the same question in many ways • To make sure we understand what the users and customers want and need

6. Requirements Elicitation • Separate the requirements into 3 categories • 3 categories • Requirements that absolutely must be met • Requirements that are highly desirable but not necessary • Requirements that are possible but could be eliminated • The purposes • If the system as defined will cost too much, or take too long to develop • Category 3 requirements can be dropped • Category 2 requirements can be analyzed for elimination or postponement

7. Requirements Elicitation • The contents of the requirements • Each of a system requirements deals with objects or entities, that states they can be, the functions that are performed to change states or object characteristics • We look for requirements that define the system objects, the limit or restriction for objects, the relationships among different or multiple objects • The criteria for an valid requirement • We can test to determine if the requirement has been met. See Sidebar 4.2, p.139 • The implementation-specific descriptions are not considered as requirements, unless they are mandated by the customer • Requirements addresses the purpose of the system without regard for its implementation • Requirements identify the what of the system • The design identifies the how

8. Requirements Elicitation • See Fig 4.2, p.138, for the process • The goal of the Requirements process • Requirements are elicited at the beginning of development, • and the goal is to determine the nature of the customer’s problem • A discussion of any solution is premature until the problem is clearly defined • The form and focus of requirements • Problem and understanding is mostly easily stated in terms of the customer’s business • And requirements should be focused on the customer and the problem, not on the solution or implementation

9. 2 Kinds of Requirements Documents • 2 separate but related purposes of requirements elicitation and analysis • The requirements should be documented in 2 forms • Requirements definition : written in terms that the customer can understand • It is complete listing of everything the customer expects the system to do • It represent the common understanding of the developer and the customer • It is usually written jointly by the developer and the customer • Requirements specification : restates the requirements definition in technical terms • It is appropriate for the development of s system design • It is the technical counterpart to the requirements definition • It is written by the requirements analysts • Often both types of documents are needed • To make sure no information is lost or changed when reinterpreting the definition as a specification

10. 2 Kinds of Requirements Documents • Requirements and Configuration Management • There must be a direct correspondence between each requirement definition and those of the specification • It is here that is used throughout the life cycle • Configuration Management is a set of procedures that track • The requirements that define what the system should do • The design module that are generated from the requirements • The code that implement the design • The tests that verify the functionality of the system • The documents that describe the system • Configuration management provides the threads that tie the system parts together, to coordinate the development activities • In this way, the customer’s view is tied to the developer’s view • In an organized and traceable way.

11. Functional and Nonfunctional Requirements • Requirements describe a system’s behavior • They cover the system and object states and the transitions from one state to another • Objects or entities move from one state to another • From empty to full, from busy to still, from sending to receiving, …… • In a given state, the system satisfies a set of conditions, when the system acts, it may change its overall state by changing the state of an object • To describe requirements, we think them in 2 ways • Functional, and • Non-functional

12. Functional and Nonfunctional Requirements • Functional requirement • It describes an interaction between the system and its environment • It describe how the system should behave given certain stimuli • We can use various techniques to determine the functional requirements, including use cases, scenarios, data flow diagrams. • Use cases partition the system into a set of logical, minimally related pieces, each of which describes some way in which the system will function. • The answers to the questions addressed by functional requirements are independent of an implementation of a solution to the customer’s problem.

13. Functional and Nonfunctional Requirements • Non-Functional requirement • It puts restrictions on the system • It describes a restriction on the system that limit our choices for constructing a solution to the problem. • The constraints usually narrow our selection of language, platform, or implementation techniques or tools • However, the selection is made at the design stage, after the requirements have been specified • Both requirements are described in a formal and careful way • Customers are not always good at describing exactly what they want or need

14. Functional and Nonfunctional Requirements • Customers are not always good at describing exactly what they want or need. • They know their business, but they cannot always describe their business problems to outside. • The descriptions are full of jargon and assumptions, which we may not be familiar. • We are not always good at understanding someone else’s business concern. • We know about computer solutions, but not always about how possible solutions will affect our customer’s business activities. • We to have our jargon and assumptions, and sometimes we think we are speaking the same language when in fact we have different meanings for the same thing. • Communication between us and our customers can lead to misunderstanding or incomplete specification.

15. 4.2 Types of Requirements • Physical Environment • Interfaces • Users and Human Factors • Functionality • Documentation • Data • Resources • Security • Quality Assurance

16. Types of Requirements • Robertson suggests several sources for requirements • See Fig 4.3, p.144 • Suggested type of requirements, existing documents, current organization and systems, stakeholder wants and needs, domain models, current situation model, re-usable requirements • Requirements can be elicited in many ways. • Review the current situation • Apprentice with the user to understand context, problem and relationships • Interview current and potential users • Make a video to show how the new system might work • Dig through existing documents • Brainstorm with current and potential users • Observe structures and patterns of the customer’s problem

17. 4.3 Characteristics of Requirements • Requirements can serve 3 purposes • Allow developers to explain their understanding • Tell designers what functionality and characteristics the resultant system is to have • Tell the test team what to demonstrate to convince the customer • To ensure both we and the customers understand and use the requirements properly, it is important that the requirements be of high quality. • To this end, we check the requirements to make sure they have the desired characteristics.

18. Characteristics of Requirements • The desired characteristics of quality requirements • Are the requirements correct ? • Both we and the customer should review them to assure that they stated without error. • Are the requirements Consistent ? • To make sure there no conflicting or ambiguous requirements. • 2 requirements are inconsistent if it is impossible to satisfy them simultaneously. • Are the requirements Complete ? • To make sure that every possible states, state changes, inputs, products, constraints and other needed things are described by some requirements.

19. Characteristics of Requirements • Are the requirements Realistic ? • To make sure there is no requirement which can not be done realistically. • Does each requirement describe something that is needed by the customer ? • A requirement may restricts the developers unnecessarily or includes functions that are not directly related to the problem at hand. • We should review the requirements to retain only those that work directly to solve the problem. • Are the requirements verifiable ? • We must be able to write tests that demonstrate that the requirements have been met.

20. Characteristics of Requirements • Are the requirements traceable ? • Can each function be traced back to a set of requirements that mandate it ? • Use this checklist to scrutinize requirements • Improving or changing them as we go.

21. Characteristics of Requirements • Example • “The system shall provide real-time response to queries.” • Question : What “real-time response” is ? • It is better written as : • “The system shall response to queries in not more than 2 seconds.” • “Accuracy shall be sufficient to support mission planning.” • How can we test to see if it satisfies this requirement ? • “In identifying the position of the satellite, position error shall be less than 50 feet along orbit, less than 30 feet off orbit.”

22. 4.4 How to Express Requirements • Requirements definition is best performed by working down from the top. • That is to Begin by expressing the general attributes of the system at the higher level. • Requirements specified in a natural language using normal sentences and phrases. • For many years they were done just in this way. • But there are several problems

23. How to Express Requirements • Requirements specified in a natural language using normal sentences and phrases. • Problems with natural language • It is unlikely that We and the customer have the same understanding of all words we use. • Natural language may not be the precise and unambiguous medium for expressing the functionality and relationship. • Requirements are not easily separated from other elements with which they deal with. • We should find ways to define requirements in a more rigorous and controlled fashion. • This approaches use formal notation to describe • In this way, tools can be developed to check for completeness and consistency, and the trace-ability

24. Static Descriptions • Static description • It lists the system entities or objects, their attributes and their relationships with each other. • It does not describe how relationships change with time • This is useful and adequate when time is not a major factor. • There are several ways to describe a system statically.

25. Static Descriptions • Static description techniques • Indirect reference • A system is described with indirect reference to the problem and its solution. • That is, the properties of the solution are given without stating the solution method. • Recurrence relations • An initial condition is defined • And the transformation from one condition to the next is described in terms of the previously defined condition • Example : Fibonacci numbers F(0) = F(1) = 1; F(n+1) = F(n) + F(n-1)

26. Static Descriptions • Static description techniques • Axiomatic Definition • This approach specifies the basic properties, and the behavior of the system generates new properties from them, called theorems. • This method demands a set of axioms that is both complete and consistent; otherwise the resulting theorems will not express truths about the system. • This type of requirements definition is well-suited to the development of an expert system. • This is often used in specifying abstract data types : a set of objects and permissible operations on these objects, and axioms specify the relationships among the objects and the operations. • Expression as a language • Requirements become a specification of the syntax of the strings • Example : regular language, which can be recognized by a finite state machine

27. Static Descriptions • Static description techniques • Data Abstraction • Is a technique for describing what data are for • We describe data type by forming a data-type dictionary. • The central idea is to categorize data and group like elements together. • Data type or class • Objects or instances • Example : student record, p.150, Fig 4.4, p.151 • Data types are indicated by italics • Braces({}) indicate something that may be repeated • Enumeration : gives the possible range of value • UML notation to describe classes and their relations • Class Inheritance, Abstract method

28. Dynamic Descriptions • Techniques for Dynamic Description • These are techniques for viewing system • In terms of changes over time • Decision Tables • Describe a system as a set of • possible conditions satisfied by the system at a given time • Rules for reacting to stimuli when certain conditions are met and actions to be taken as a result • Table 4.1, p .152 • Columns represent conditions or states of the system • T:True, F:False, -:dash, condition dos not matter

29. Dynamic Descriptions • Decision tables • This can generate very large tables • The number of the states is equal to the number of combinations of conditions, which is 2n • There may exist redundant rules which are covered by other rules • We can reduce the size and make them easier to understand • What can the table tell us about the requirements ? • If every possible set of conditions results in an action, then the requirements specification is complete • And we can examine the table for consistency and eliminate any conflicting cases.

30. Dynamic Descriptions • Functional description and transition diagrams • We can view a system in a similar manner as a set of states where the system reacts to certain events • The system’s behavior is interpreted as a series of functions • Each function represent a transition from some inputs to outputs • We can depict this transition by drawing a diagram of the movement of the system from one state to another • We draw a circle for each state in the system • And a directed arrow to indicate the transition

31. Dynamic Descriptions • Functional description and transition diagrams • We can express each system transition as f (Si,Ci) = Sk • Fig 4.5, p.153 • Other notations for depicting state transitions • Fig 4.6, p.154, fence diagram • UML state transitions diagram, see Fig.4.7, p.154 • Example Fig 4.8, p.155 • It is important to separate expectations or assumptions from what the requirements are actually saying. See Sidebar 4.5, p.155, Fig 4.9

32. Dynamic Descriptions • Event Tables • System states and transitions can be represented in an Event Table • Vertical axis consists of the states or sets of conditions • Along the Horizontal axis, we place the events • The cells contain the actions that take place when the event at the top of the column occurs • Example : Table 4.3, p.156

33. Dynamic Descriptions • Petri Nets • The need for representing concurrency • When several events occur at once, sometime a system must perform parallel processing • A major problem in this case is the need to synchronize events • Several events may occur in parallel but are performed in an unpredictable order.

34. Dynamic Descriptions • Petri Nets • We can extend the notion of transition to describe synchronization and parallel • In this situation, several events trigger the move from one to another state • F(StateA, Event1,…,EventN) -> StateS • In more general, once the transition is initiated, the system may moves into several states in parallel • F(StateA, Event1,…,EventN) -> State1,…,StateM • The complicating factor here is the need for coordination • The activities are occurring in parallel, and • We need some way to control the collection of events to change states

35. Dynamic Descriptions • Petri Nets • Petri Net is an alternative that is well suited for expressing parallel processing requirements • Fig 4.10, p.158 • To handle the coordination of events and states, each state is associated with a set of tokens,Fig 4.10, p.158 • The tokens represent events. Once it occurs, a token may travel from one state to another • Transitions are described by a set of firing rules • Each firing rule explains how tokens are associated with a state • When the correct number and type of tokens are present in one state, tokens are released to travel to another state

36. Dynamic Descriptions • Petri Nets • Transitions are described by a set of firing rules • Thus, the firing rules correspond to transition functions • Tokens and firing rules allows the Petri Net to represent and synchronize activities that may be taking place concurrently • When the conditions for each state are met, the tokens are ready to fire. In this way, the tokens synchronize events • After the tokens have fired, the result is the movement of tokens to the other side of the transition.

37. Dynamic Descriptions • Object-Oriented Specification • Object-Oriented is sometimes more appropriate to write requirements • Object-Oriented approach views the a system as a set of independent objects and their relations • Rather than as a set of input/output transformations • Key concepts of Object-Oriented • Object : encapsulation, attributes and methods • Class : objects with the same structure and interfaces • Class inheritance : generalization, specialization • Polymorphism : abstract methods can be defined for more than one class of objects

38. Dynamic Descriptions • Object-Oriented Specification • Object-Oriented requirement specification • 3 models of OMT (Object Modeling Technology) • Object model, dynamic model, functional model • UML (Unified Modeling Language) • use-case views, logical views, component views, concurrency views, deployment views • Or static views, dynamic views, physical views, workflow • use-case diagram, class diagram, object diagram, state diagram, sequence diagram, collaboration diagram, activity diagram, component diagram, deployment diagram • See Chapter04 reference 1 on 面向对象分析与设计UML

39. 4.5 Additional Requirements Notations • Warnier Diagrams • Data flow diagrams • Software Requirements Engineering Methodoly • Structured Analysis and Design Technique • Z

40. Warnier Diagrams • Warnier Diagrams • Using a tree of items connected with braces({) and special symbols • braces({) differentiate the levels • The symbols show conditional relationships among data elements • The hierarchies are shown from left to right • See Fig 4.13 for example, p.161 • A Plus enclosed in a circle indicates mutually exclusive relation of data items • A solid circle indicates concatenation • Number enclosed in parentheses indicates multiple copies of data item

41. Data Flow Diagram (DFD) • DFD is used to exhibit the requirements for the flow of data, and the relations with functions • This is a technique of requirements hierarchy • The hierarchies are expressed by layering • So that different levels of detail are shown in different layers • DFD Considers the system as a or a set of transformer of data • A diagram is used to show • the data that flow into the system • How they are transformed, and • How they leave the system

42. Data Flow Diagram (DFD) • See Fig 4.14 for symbols in DFD, p.162 • Using arrows to represent Data flows, or data path, in and out • Using ovals to represent processes or transformers • Which will process the input data and produce the output data • Using parallel bars to represent data stores, which are formatted data items that may reside in a data repository or database • Data stores usually are referred to as persistent data or information • Using rectangles to represent actors or external entities • They may provide or receive data to the processes

43. Data Flow Diagram (DFD) • See Fig 4.15 for example, p.162 • Requirements Hierarchy • DFD depicts a high-level view of the system • Each process bubble can be represented as a separate diagram to show the details of the data transformation • In this way, the requirements hierarchy is formed. • See Chapter04 reference 2 on 结构分析设计

44. SREM • SERM : Software Requirements Engineering Methodology • To deal with the difficulties in generating requirements for real-time systems • SERM has 2 parts • 1 for specification and 1 for analysis and reporting • Writing Requirements in RSL • RSL : Requirements Specification Language • A system is described in terms of objects and their relationships • RSL describes the flow of processing in terms of what events initiate which processing

45. SREM • Writing Requirements in RSL • The flows are represented as a network • By using both pictures and written descriptions • The network, also called R-net, specifies how a state and single input are transformed into a new state with a set of output messages • See Fig 4.16, p.163, for structure and example • A circled plus indicate a condition or branching • A circled ampersand indicates the possible parallel processes • A triangle indicates point of synchronization • All parallel processes must be completed before the next process can begin

46. SREM • The network diagram can be translated into its corresponding RSL statements • See example in p.164 • Other elements in SREM • Alpha is a specification for the functions in an R-net • Each function includes its input, output and the description of the transformation • Data element for definition of data structure • Including the fields of each element, where each element originates and a general description

47. SREM • Other elements in SERM • Validation point is a place in the diagram to denote the beginning or the end of a measurement or restriction • ASSM : Abstract System Semantic Model • This is a database formed from the RSL statements • assisted by a set of tools, a variety of reports can be produced • Summary reports • Critical processing requirements • See Table 4.4 for the steps using SREM • SYSREM adds time dimension • Allows to specify a sequence of events or concurrency

48. Structured Analysis and Design • SADT : Structured Analysis and Design Technique • Also known as IDEF0 in U.S. Dept. of Defense • It consists of 2 parts • SA : Structured Analysis, specifies the requirements using 2 types of diagrams • DT : Design Technique, explains how to interpret the results • IDEFx is a series of schemes for expressing software requirements and designs • IDEF0(functional),IDEF1(data model),IDEF3(design model), IDEF4(object-oriented), IDEF5(ontology model)

49. Structured Analysis and Design • Basic SA diagram • This is a functional diagram • Each diagram represent a transformation • It consists of 4 factors : input, output, controls and mechanisms • See Fig 4.17, p.166 • The diagram are arranged in a hierarchy to show more details at lower levels • Normally, each diagram consists at most 6 diagrams at each lower level • SADT is also useful in depicting software process

50. Z notation • Z is A Formal Specification Language • It express requirements in mathematical way • They can be evaluated using proofs and automated techniques • It provides • A universe of objects • And a set of precise rules defining objects • See Chapter04 reference 3 on Z标记语言