1 CEN 4020 Software Engineering PPT4: Requirement analysis

2 Process for capturing requirements Requirements are expressions of desired behavior. It is what something can do and what states that something can be in. Steps of capturing requirements Capturing requirements can be broken down into the following parts: Elicitation – collecting requirements as defined by the user Analysis – Comprehending and modeling the behavior that is expected Specification – Recording the behavior of the proposed system Validation – Ensuring that the specs proposed meet the requirements of the user

3 Process for capturing requirements The above figure illustrates the process of capturing requirements explained on the previous slide.

4 How users and developers view each other How developers view users Users often change their minds because they weren’t sure what they wanted in the first place. How users view developers Developers often have trouble remembering to talk in very high- level terms to the user. The developer has to remember that the user doesn’t have a computer science degree.

5 How users and developers view each other

6 Sources of requirements

7 Requirement documentation There are two kinds of requirements documents Requirements definition – documents specifying everything the customer wants to accomplish Requirements specification – reaffirms the requirements as a specification of behavior of the proposed system

8 Importance of requirement analysis

9 Take away points from the previous slide – It is important to note that over 13% of failed projects are caused by incomplete requirements with lack of user involvement being the second most common cause. Cost of fixing a bug: $1 to fix a requirement-based problem $5 to fix the problem at design time $10 to fix during coding $20 during unit testing $200 after delivery of the system

10 Types of requirements The different forms of requirements are the following: Quality requirement – A quality trait that the software solution needs to have (ex.: intuitive/easy to use) Design constraint – Design decision that decreases number of solutions to the proposed problem Process constraint – A constraint on the resources that can be used to implement the system.

11 Characteristics of requirements The following characteristics are wanted of requirements: Requirements that are correct Requirements that are consistent Requirements that are clear Requirements that are complete Requirements that are achievable Requirements that are relevant Requirements that can be tested Requirements that can be traced

12 Modeling notations Entity-Relationship Diagram Graphical notational paradigm for representing conceptual methods

13 Modeling notations UML Class Diagram Unified Modeling Language (UML) Collection of notations used to document software specs and designs

14 Modeling notations Event Trace A graphical description of a sequence of events that are exchanged between real-world entities. Vertical lines represent the timeline for an entity Horizontal lines represent an interaction between two entities bounding that line

15 Modeling notations Message Sequence Chart An enhanced event-trace notation, with conveniences for making and removing entities, specifying actions and timers, and building traces

16 Modeling notations State Machine Graphical description of interaction between the system and environment Nodes represent states Edges represent transitions between states

17 Modeling notations UML State-chart Diagram Dynamic behavior of objects in a UML class Shows how instances of a class should change state and how their fields should change value throughout object interaction

18 Modeling notations Petri Nets Form of state-transition notation that is used to exemplify activities and their interactions

19 Modeling notations Data flow diagram Models functionality and flow of data from one function to another Use case diagram Depicts observable, user-initialized functionality in terms of interactions between system and environment

20 Modeling notations Formal methods Mathematically based specs and design techniques Decision Table Tabular representation of a functional spec that maps events and circumstances to corresponding actions

21 Modeling notations Parnas Table Collection of table types and abbrev. plans for forming and simplifying functional and relational expressions First order logic – commonly used to express properties of software requirements Temporal logic – used to express pending changes over time

22 Modeling notations Object constraint language Constraint language that is mathematically precise and high-level (for non-mathematic people)

23 Modeling notations Z Requirements spec language that forms set-theoretic definitions of variables into a abstract-data-type model

24 Prototyping requirements Two approaches to prototyping Throwaway prototyping Developing software to learn more about the solution to a problem and the problem itself Not part of the final product Evolutionary prototyping Software developed to comprehend the problem and the solution Incorporated into the final product Rapid prototyping comprises both throwaway and evolutionary prototyping because software is developed to learn more about the requirements

25 Prototyping requirements Examples (Prototypes for a calendar system)

26 Documenting requirements Documentation is needed for each team to have the ability to make contributions and ensure the requirements are understood The definition document is a document of the requirements expressed by the customer It is what the customer should see from the final product Outline the system’s general purpose and scope The reason behind the proposal for a new system The important features of a suitable solution System’s environment Description of the customer’s potential proposal for a solution to the problem Assumptions about environment behavior

27 Documenting requirements The specification document is a document similar to the definition document expressed by the developer This document is written in terms of the product’s interface Description of inputs, outputs, and other topics pertaining to the system interface Required functionality of the system regarding inputs and outputs Conditions for the customer’s feature requirements

28 IEEE standard for requirement specification The IEEE standard provides outlines for organizing the requirements specification by categories including capability and user type

29 Participants in the requirement process There are many sources that have something to give towards the requirements The clients – decision makers The customers – Important to build something that attracts the customer. May also be a user The users – Very familiar with the system. May also be the customer. Domain experts – Knowledgeable of the field in which the system will be used Market researchers – Know about potential customers Lawyers – Ensure that no legal boundaries are crossed Tech experts – Contribute to customer education

30 Validation and verification The requirements documents act as a contract between the developers and the customer The requirements should be reviewed to ensure validation and verification Requirements validation Ensure the requirements definition match customer needs Requirements verification Ensure that building a system according to the requirements specification document will be a final product that will meet the customer’s requirements

31 Validation and verification

32 Measuring requirements Requirements can be measured in several different ways Measurements often focus on product, process, and resources Requirement readiness (see the example below depicting a scale 1 to 5)

33 Choosing a specification language Selection criteria Applicability Implement ability Testability Check ability Maintainability Modularity Abstraction level Soundness Verifiability Runtime safety Tools maturity Looseness Learning curve Technique maturity Data modeling Discipline

34 Choosing a specification language

35 Examples of modeling notations

36 Examples of modeling notations

37 Examples of modeling notations

38 References Information and illustrations from: Pfleeger and Atlee, Software Engineering Theory and Practice, 4 th Edition.