Requirements Engineering process

Transcription

1 Requirements Engineering process Used to discover, analyze, validate and manage requirements Varies depending on the application domain, the people involved and the organization developing the requirements However, there are a number of generic activities common to all processes: feasibility study requirements elicitation and analysis requirements specification requirements validation requirements management UniRoma2 - Service-oriented Software Engineering 1

2 Feasibility study A short focused study that checks If the product contributes to organizational objectives If the product can be engineered using current technology and within budget If the product can be integrated with other products that are used Based on a concise description of the product and the user needs Produces a report that decides whether or not the proposed product is worthwhile UniRoma2 - Service-oriented Software Engineering 2

3 Feasibility study (2) The required info are collected by interviewing: client manager software engineers with skills in the specific application domain experts of technology to be used end users Example typical questions: What if the product wasn t implemented? What are current process problems? How will the proposed product help? What will be the integration problems? Is new technology needed? What skills? What facilities must be supported by the proposed product? UniRoma2 - Service-oriented Software Engineering 3

4 Requirements elicitation and analysis Sometimes called requirements discovery Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system s operational constraints May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders (i.e., people who may have a direct or indirect interest in the product requirements) UniRoma2 - Service-oriented Software Engineering 4

5 Problems of requirements analysis Stakeholders don t know what they really want Stakeholders express requirements in their own terms Different stakeholders may have conflicting requirements Organizational and political factors may influence the product requirements The requirements change during the analysis process New stakeholders may emerge and the business environment change UniRoma2 - Service-oriented Software Engineering 5

6 Requirements elicitation and analysis process UniRoma2 - Service-oriented Software Engineering 6

7 Req. elicitation and analysis (2) Requirements elicitation techniques Ethnography Use cases (scenarios-based) Prototyping Requirements analysis (and specification) techniques semi-formal, based on system models and used by structured analysis methods or object-oriented analysis methods formal (based on formal languages, such Petri Net, FSM, Z, etc.) UniRoma2 - Service-oriented Software Engineering 7

8 Requirements validation Concerned with demonstrating that the requirements define the product that the customer really wants Very important to avoid costly requirements reworks in later lifecycle phases Checks include: validity: does the system provide the functions which best support the customer s needs? consistency: are there any requirements conflicts? completeness: are all functions required by the customer included? realism: can the requirements be implemented given available budget and technology verifiability: can the requirements be checked? UniRoma2 - Service-oriented Software Engineering 8

9 Requirements validation techniques Informal reviews Formal reviews walkthroughs inspections Prototyping Test-case generation Automated consistency analysis (for requirements specified in formal languages) UniRoma2 - Service-oriented Software Engineering 9

10 Requirements management The process of managing changing requirements during the requirements engineering process and product development Classification of requirements in terms of evolution: enduring requirements (low probability of change) volatile requirements (high probability of change): mutable requirements (requirements that change due to the system s environment) emergent requirements (requirements that emerge as understanding of the product improves) consequential requirements (requirements that result from the introduction of the computer system) compatibility requirements (requirements that depend on other systems or organizational processes) UniRoma2 - Service-oriented Software Engineering 10

11 Requirements management planning During the requirements engineering process, you have to plan: requirements (unique) identification change impact analysis in terms of costs and feasibility traceability policies relationships between requirements, their sources and the system design CASE tool support the tool support required to help manage requirements change UniRoma2 - Service-oriented Software Engineering 11

12 Formal vs. informal specification UniRoma2 - Service-oriented Software Engineering 12

13 Formal specification with Petri Net Transition Place UniRoma2 - Service-oriented Software Engineering 13

14 Marked Petri Net (1) Token UniRoma2 - Service-oriented Software Engineering 14

15 Marked Petri Net (2) after firing transition t 1 UniRoma2 - Service-oriented Software Engineering 15

16 Marked Petri Net (3) after firing transition t 2 UniRoma2 - Service-oriented Software Engineering 16

17 Petri Net: example Inhibitor arc UniRoma2 - Service-oriented Software Engineering 17

18 Formal specification with Finite State Machine (FSM): example Input State UniRoma2 - Service-oriented Software Engineering 18

19 Formal specification with Z Consists of a set of schemas Schema template: UniRoma2 - Service-oriented Software Engineering 19

20 The Z language state specification example Abstract Initial State Button_init := [Button_State pushed = Æ] UniRoma2 - Service-oriented Software Engineering 20

21 The Z language operation specification example UniRoma2 - Service-oriented Software Engineering 21

22 Semi-formal specs: system models A system model is an abstract representation of a system, produced to facilitate the understanding of the system behavior and properties at system development time System models are produced by requirements analysis (specification) methods that make use of semi-formal techniques Such requirements analysis methods can be: structured (or procedural) analysis methods object-oriented analysis methods For a complete system description it is necessary to represent various aspects (data, behavior and control) UniRoma2 - Service-oriented Software Engineering 22

23 Model types data model: to represent the static and structural aspects (data requirements) ERD (not UML) class diagram (UML) behavioral model: to represent the functional aspects (functional requirements) data flow diagram (not UML) use case diagram (UML) activity diagram (UML) interaction diagram (UML) dynamic model: to represent the control aspects, as well as how the functions of the behavioral model modify the data of the data model state diagram (UML) UniRoma2 - Service-oriented Software Engineering 23

24 Entity Relationship Diagram (ERD) one-to-many relations UniRoma2 - Service-oriented Software Engineering 24

25 ERD many-to-many relations UniRoma2 - Service-oriented Software Engineering 25

26 Data Flow Diagram (DFD) UniRoma2 - Service-oriented Software Engineering 26

27 DFD example first refinement UniRoma2 - Service-oriented Software Engineering 27

28 DFD example second refinement process orders expansion UniRoma2 - Service-oriented Software Engineering 28

29 Structured System Analysis (SSA) (structured analysis method) Introduced by Gane and Sarson (1979) Composed of 9 steps Based on step-wise refinement Other structured analysis methods: DeMarco (1978) Yourdon and Constantine (1979) UniRoma2 - Service-oriented Software Engineering 29

30 SSA Step 1 Draw the DFD Use the requirements document (or the prototype) to: Identify data flows Identify source and destinations of data (where data flows starts and ends, respectively) Identify processes that transform data Refine the DFD by adding new flows of data or by adding details to existing data flows UniRoma2 - Service-oriented Software Engineering 30

31 SSA Step 2 Decide what Sections to Computerize and How Use cost-benefits analysis to decide which sections of the DFD to automate Decide how to computerize: Batch operations On-line processing Example: Automate order placement in batch Automate order validation online The next 3 steps are the stepwise refinement of data flows, processes and data stores UniRoma2 - Service-oriented Software Engineering 31

32 SSA Step 3 Determine the details of the data flows Decide what data items must go into the various data flows Example: the data flow order can be refined as follows: order_identification customer_details package_details Then, refine each flow stepwise: order_identification is a 12-digit integer customer_details consists of customer_name, customer_address, etc. UniRoma2 - Service-oriented Software Engineering 32

33 SSA Step 4 Define the logic of processes Example: build the decision tree for a give_educational_discount process UniRoma2 - Service-oriented Software Engineering 33

34 SSA Step 5 Determine the data stores Define the exact contents of each store and its representation (specific format in a given programming language) Define the level of access by use of data-immediateaccess diagram (DIAD) Example: UniRoma2 - Service-oriented Software Engineering 34

35 SSA Step 6 Define the physical resource Examples: For each file, specify: file name, organization (sequential, indexed, etc.), storage medium, records, down to the field level If a DBMS is to be used, then the relevant information for each table is specified UniRoma2 - Service-oriented Software Engineering 35

36 SSA Step 7 Determine the Input/Output specifications The input forms must be specified (components and layout) The output screens must similarly be determined The printed output also must be specified (estimated length and details) UniRoma2 - Service-oriented Software Engineering 36

37 SSA Step 8 Determine the sizing Compute: volume of input (daily or hourly) frequency of each printed report and its deadline size and number of records that are to pass between the CPU and mass storage size of each file UniRoma2 - Service-oriented Software Engineering 37

38 SSA Step 9 Determine the hardware requirements From sizing information specified at step 8, determine: Mass storage requirements Mass storage requirements for backup Characteristics of user terminals Characteristics of output devices Adequacy of existing hardware Costs of hardware to be purchased UniRoma2 - Service-oriented Software Engineering 38

39 SSA Output Step 9 is the last step of SSA After approval by the client, the resulting specification document is handed to the design team, and the software process continues Drawbacks: SSA cannot be used to determine response times CPU size and timing cannot be determined with any degree of accuracy UniRoma2 - Service-oriented Software Engineering 39