1. 1 Capturing The Requirements CEN 4020 Software Engineering By Darren Quichocho

2. Requirements What is a requirement? ◦An expression of desired behavior ◦Deals with objects or entities, the states they can be in, and the functions that are performed to change those states and characteristics ◦It is important to note that the requirements focus on the customer and the problem, not on the solution or implementation 2

3. Forms of Requirements Requirements can loosely be prioritized into three categories ◦Essential – requirements that must be absolutely met ◦Desirable – requirements that are highly desirable but not necessary ◦Optional – Requirements that are possible but could be eliminated We’ll use a credit card billing system as an example ◦Essential – list current charges, sum them, and request payment ◦Desirable – the ability to separate the charges by purchase-type ◦Optional – Printing the credits and debits in different colors 3

4. Steps of Capturing Requirements The requirements are usually decided by a Requirements Analyst or a Systems Analyst The end result is a Software Requirements Specification (SRS) ◦Used to communicate to other software developers how the final product should behave. 4

5. How Users and Developers View Each Other 5 Identifying the requirements that the user or customer wants is not always easy. Often, the customer does not actually know what they want or simply cannot accurately describe their needs. In the same way, developers may not always understand business concerns or jargon. As a result, the process of eliciting requirements can be lengthy.

6. Types of Requirements Functional – describes required behavior in terms of required activities such as reactions to inputs or the state of each entity before and after an activity occurs Quality or Nonfunctional – describes some quality characteristic that the software solution must process such as fast response time, ease of use, high reliability, or low maintenance cost Design Constraint – a design decision, such as choice of platform or interface components, that has already been made and that restricts the set of solutions to the problem Process Constraint – a restriction on the techniques or resources that can be used to build systems 6

7. Requirements Documents Requirements Definition – a complete listing of everything the customer wants to achieve ◦Aimed at a business audience, such as clients, customers, and users ◦Typically written jointly by the client and the requirements analyst ◦Written entirely in terms of the environment, describing how the environment will be affected by the proposed system Requirements Specification – restates the requirements as a specification of how the proposed system shall behave ◦Aimed at a technical audience, such as designers, testers, and project managers ◦Also written in terms of the environment, except that it refers solely to the entities that are accessible to the system ◦Written by the requirements analyst and used by developers 7

8. Requirements Documents Below is a depiction of the separation between the requirements definition and the requirements specification 8

9. Importance of Requirements Analysis If the requirement analysis phase is not completed properly or in a sluggish manner then there might be inconsistencies in the final product. Top Factors of Failed Projects: 1. Incomplete Requirements (13.1%) 2. Lack of User Involvement (12.4%) 3. Lack of Resources (10.6 %) 4. Unrealistic Expectations (9.9%) 5. Lack of Executive Support (9.3%) 6. Changing Requirements and Specifications (8.7%( 7. Lack of Planning (8.1%) 8. System No Longer Needed (7.5%) 9

10. Characteristics of Requirements 1. Are the Requirements Correct? ◦Both the developer and the customer should agree on the set of requirements 2. Are the Requirements Consistent? ◦Requirements are inconsistent if they are impossible to satisfy simultaneously 3. Are the Requirements Unambiguous? ◦Requirements are ambiguous if multiple people can read them and walk away with different but valid interpretations 4. Are the Requirements Complete? ◦They are complete if it specifies required behavior and output for all possible inputs in all possible states under all possible constraints 10

11. Characteristics of Requirements 4. Are the Requirements Consistent (cont.)? ◦Externally Complete – all states, state changes, inputs, products, and constraints are described by some requirements ◦Internally Complete – no undefined terms among the requirements 5. Are the Requirements Feasible? ◦Feasibility comes into play when a customer requires two or more quality requirements. For example, they want an inexpensive system that analyzes huge amounts of data and outputs an analysis in seconds. 6. Are the Requirements Relevant? ◦Need to stay focused on essential and desirable requirements. Requirements that are not relevant can end up limiting the developer 11

12. Characteristics of Requirements 7. Are the Requirements Testable? ◦Testable if they suggest acceptance tests that would clearly demonstrate whether the eventual product meets the requirements 8. Are the Requirements Traceable? ◦The requirements should be organized and uniquely labeled for easy reference 12

13. Modeling Notation Entity Relationship Diagram (ER Diagram) – graphical notational paradigm used to model the relationships among objects in a problem description or to model the structure of a software application 13 Entity (rectangle) – objects with common properties or behaviors Relationship (diamond) – specifies type of relationship between entities Attribute (annotation) – describes data or property of an entity

14. Modeling Notation Unified Modeling Language (UML) – collection of notations used to document software specifications and designs ◦Typically uses a class diagram – a sophisticated ER diagram relating the classes in the specification. Each class has a name, a set of attributes, a set of operations ◦Class-scope attribute – (underlined attribute) a data value that is hared by all instances of the class ◦Class-scope operation – (underlined operation) operation performed by the abstract class on a new instance ◦Association ◦Aggregate – “has a” association represented by a white diamond ◦Generalization – “is a” association represented by a triangle on one end ◦Association Class – relates attributes and operations to an association 14

15. Modeling Notation An example UML chart 15

16. Modeling Notation Event Trace – a graphical description of a sequence of events that are exchanged between real-world entities. Traces are preferred because of they are relatively precise but also easy to understand The trace on the left represents typical behavior and the trace on the right represents the expected behavior 16

17. Modeling Notation Message Sequence Charts – an enhanced event-trace notation with facilities for creating and destroying entities, specifying actions and timers, and composing traces ◦Vertical line represents a participating entity ◦A message is depicted as an arrow from the sending entity to the receiving entity ◦Actions are specified as labelled rectangles positioned on an entity's execution line ◦Conditions are important states in an entity's evolution, represented as labelled hexagon 17

18. Modeling Notation Message Sequence chart for a library loan transaction 18

19. Modeling Notation State Machines – a graphical description of all dialog between the system and its environment. Useful in representing dynamic behavior 19 State – each node represents a stable set of conditions that exists between event occurrences Transition – represents a change in behavior or condition due to the occurrence of an event Deterministic – a state machine is deterministic if for each state and event there is a unique response

20. Modeling Notation UML State Chart Diagram – depicts the dynamic behavior of the objects in a UML class. Gives a static big picture view of a problem 20 Uses state hierarchy to simplify diagrams by using superstates which combine states with common transitions A superstate can be thought of as a submachine Submachines operate concurrently, meaning that an instance could at any time receive and respond to events of interest to either submachine

21. Modeling Notation Petri Nets – a form of state transition notation that is used to model concurrent activities and their interactions ◦Circles (places) represent activities or conditions ◦Bars represents transitions ◦Arcs connect a transition with its input places and its output places ◦The places are populated with tokens, which act as enabling conditions for the transitions ◦Each arc can be assigned a weight that specifies how many tokens are removed from arc's input place, when the transition fires 21

22. Modeling Notation 22 Petri Net for the behavior of a book loan

23. Modeling Notation Data Flow Diagram (DFD) – models functionality and the flow of data from one function to another ◦A bubble represents a process ◦An arrow represents data flow ◦A data store: a formal repository or database of information ◦Rectangles represent actors: entities that provide input data or receive the output result 23

24. Modeling Notation DFD for a library loan system 24

25. Modeling Notation Use-Case Diagram – depicts observable, user initiated functionality in terms of interactions between the system and its environment 25

26. Modeling Notation Formal Methods or Approaches – mathematically based specification and design techniques. ◦Model requirements or software behaviour as a collection of mathematical functions or relations that map systems inputs to system outputs ◦Encouraged by many software engineers who build safety critical systems ◦For example, Defence Standard 00-56, a British standard for building safety critical systems, requires that formal specification and design be used to demonstrate required functionality, reliability and safety 26

27. Modeling Notation Decision Tables – a tabular representation of a functional specification that maps events and conditions to appropriate responses or actions 27 Specification is informal because the inputs and outputs may be expressed in natural language, as mathematical expressions, or both. Useful in examining consistency and correlations

28. Modeling Notation Parnas Tables – tabular representations of mathematical functions or relations. A collection of table types and abbreviation strategies for organizing and simplifying functional and relational expressions ◦The column and row headers are used to specify cases ◦The internal table entries store the possible function results ◦An entry “X” either could be invalid under the specified conditions or the combination of conditions is infeasible 28

29. Modeling Notation First Order Logic – commonly used to express properties of software requirements. Comprising typed variables, constants, functions, predicates, like relational operators, equality, logical connectives, and quantifiers. Temporal Logic – introduces additional logical connectives for constraining how variables can change value over time Object Constraint Language (OCL) – an attempt to create a constraint language that is both mathematically precise and easy for nonmathematicians, like customers, to read, write, and understand 29

30. Modeling Notation A partial library class model with three classes annotated with OCL constraints 30

31. Modeling Notation Z – (pronounced “zed”) a formal requirements-specification language that structures set-theoretic definitions of variables into a complete abstract-data-type model of a problem, and uses logic to decompose a specification into manageably sized modules, called Schemas. ◦Schemas specify: ◦The system state in terms of typed variables, and invariants on variables values ◦The systems initial state ◦Operations ◦Z offers the precision of a mathematical notation, such as being able to evaluate specifications using proofs or automated checks 31

32. Model Notation Library example specified in Z 32

33. Prototyping Requirements Throwaway Prototype – software that is developed to learn more about a problem or about a proposed solution and is never intended to be part of the delivered software Evolutionary Prototype – software that is developed not only to help us answer questions but also to be incorporated in the final product Rapid Prototyping – both throwaway and evolutionary prototype are sometimes referred to as rapid prototyping because they involve building software in order to answer questions about the requirements 33

34. Prototyping Requirements 34 A simple representation of a key-board entry prototype A slightly more developed calendar-based prototype A more sophisticated prototype that will most likely provide the fastest selection

35. Documenting Requirements It is important to keep a set of documents that defines the requirements. These documents need to be clear and contain precise diagrams so that both the customer and the developer may refer back to them throughout the development process. Consistency is key in documenting requirements. As we discovered before there are two main documents: ◦Requirements Definition ◦Requirements Specification 35

36. Documenting Requirements Requirements Definition 1. Outline general purpose and scope of the system 2. Describe background and rationale for proposal 3. Describe essential characteristics and core functionality of solution 4. Describe the environment in which the system will operate, taking into account the background and capability of the intended user 5. Evaluate customers proposal for the problem checking for design constraints 6. Describe any assumed environmental conditions that could cause the system to fail 36

37. Documenting Requirements Requirement Specification 1. Document system interface, describing all inputs and outputs in detail, including sources, destinations, data formats, and timing constraints. 2. Restate the required functionality in terms of the interfaces inputs and outputs. This can include data-flow diagrams, state machines, event traces, and entity-relationship diagrams. 3. Devise fit criteria for the quality requirements to demonstrate whether the system meets the needs of the customer. 37

38. IEEE Standards for Requirements Specification 38 1. Introduction to the Document 1.1 Purpose of the Product 1.2 Scope of the Product 1.3 Acronyms, Abbreviations, Definitions 1.4 References 1.5 Outline of the rest of the SRS 2. General Description of Product 2.1 Context of Product 2.2 Product Functions 2.3 User Characteristics 2.4 Constraints 2.5 Assumptions and Dependencies 3. Specific Requirements 3.1 External Interface Requirements 3.1.1 User Interfaces 3.1.2 Hardware Interfaces 3.1.3 Software Interfaces 3.1.4 Communications Interfaces 3.2 Functional Requirements 3.2.1 Class 1 3.2.2 Class 2 … 3.3 Performance Requirements 3.4 Design Constraints 3.5 Quality Requirements 3.6 Other Requirements 4. Appendices 1. Introduction ◦Purpose ◦Scope ◦Definitions, acronyms, and abbreviations ◦References ◦Overview 2. Overall description ◦Product perspective ◦Product functions ◦User characteristics ◦Constraints ◦Assumptions and dependencies 3. Specific requirements An IEEE SRS should follow the general format below. To the right is a more detailed example using classes and objects.

39. Participants and Their Roles Clients: pay for the software to be developed Customers: buy the software after it is developed Users: use the system Domain experts: familiar with the problem that the software must automate Market Researchers: conduct surveys to determine future trends and potential customers Lawyers or auditors: familiar with government, safety, or legal requirements Software engineers or other technology experts: design the system 39

40. Validation and Verification It is essential for the requirements to meet the customers needs. As a result we must verify and validate them before starting development. Requirements Validation – checks that our requirements definition accurately reflects the customers needs. Requirements Verification – we check that one document conforms to another, that is, we check that the code conforms to the design, and that the design conforms to the requirements specification. In short, validation checks that we build the system right, and verification checks that we build the right system. 40

41. Validation and Verification 41 The table provided lists techniques that can be used validate and verify requirements

42. Measuring Requirements Measuring requirements usually focuses on 3 aspects: 1. Product 2. Process 3. Resources It is also important to track: ◦Requirements size – give us a sense of the size of the system ◦Requirements Change - the number of changes can indicate and unstable system or an uncertain understanding of the system. ◦These should both be tracked by requirements type. 42

43. Measuring Requirement Each requirement can also be rated on a scale of 1 to 5 1.You understand this requirement completely, have designed systems from similar requirements, and have no trouble developing a design from this requirement 2.Some elements of this requirement are new, but they are not radically different from requirements that have been successfully designed in the past 3.Some elements of this requirement are very different from requirements in the past, but you understand the requirement and can develop a good design from it 4.You cannot understand some parts of this requirement, and are not sure that you can develop a good design 5.You do not understand this requirement at all, and can not develop a design 43

44. Choosing Specification Techniques Criteria for selecting specification techniques: ◦Applicability ◦Implementability ◦Testability ◦Checkability ◦Maintainability ◦Modularity ◦Level of Expressability ◦Soundness 44 ◦Verifiability ◦Runtime Safety ◦Tools Maturity ◦Looseness ◦Learning Curve ◦Technique Maturity ◦Discipline

45. Sources http://www.cse.msu.edu/~cse870/IEEEXplore-SRS-template.pdf http://modeling-languages.com/how-users-and-programmers-see- each-other/http://modeling-languages.com/how-users-and-programmers-see- each-other/ Software Engineering: Theory and Practice​ S. L. Pfleeger and J. M. Atlee​ Prentice Hall, Latest Edition 45