1. 1 Week 5 Software Engineering Spring Term 2016 Marymount University School of Business Administration Professor Suydam

2. 2 MP1 Observations/Discussion Use Case Review/Summary Case Study 2 Discussion Chapter 6 Requirements

3. 3

4. 4

5. 5

6. 6

7. 7

8. 8

9. 9

10. 10

11. 11

12. 12

13. 13 Clear requirements are needed for design and implementation activities. Requirements documentation is needed to: create test cases and test scenarios - - - especially for large systems where the test team is a separate group of people from the developers. control potential scope-creep. create user training material, marketing material, and documents for support and maintenance. provide a way to segment a large project, prioritize releases, and easier project management

14. 14 Requirements: May be given to the software engineers Initial product/system requirements For second and/or third follow-on release of a “planned” sequences of software product where a preliminary set of requirements are already established Requirements provided as a part of a request for price quotation for a software development project Have to be established by software engineers Users sometimes have an understanding of only the requirements related to their specific job tasks The business rationale and goals are not always clear to individual user and needs to be established for prioritization reason There may be contradicting and incomplete requirements stated by the users and customers

15. 15

16. 16 Requirements “analysis” is composed of: Categorizing the requirements (by some criteria) Prioritizing the requirements Most High Level: Functional Non-functional Other more detailed grouping also exist 6 dimensions of requirements

17. 17 View Oriented Requirements Definition (VORD) is based on the concept that requirements are viewed differently by different people: Identify stakeholders and their viewpoints of the requirements Categorize the viewpoints of requirements and eliminating any duplication (look for consistency & completeness) Refine the identified viewpoints of requirements Map the viewpoints of requirements to the system and the services that the system must provide

18. 18 Most of the time we have some limitations in developing software: Time Resources Technical capabilities (existing) We need to prioritize the requirements to satisfy these limitations Some Criteria for prioritization: Current user/customer demands or needs Competition and current market condition Anticipated future and new customer needs Sales advantages Existing critical problems in current product These are often subjective and requirements should be prioritized with the help of many of the stakeholders (different viewpoints).

20. 20 Once the requirements are solicited, analyzed and prioritized, more details may/must be spelled out. Three major activities which may be intertwined must be performed: Requirements definition Requirements prototyping Requirements reviewing

21. 21 Requirements definitions may be written in different forms: 1.Simple Input/Process/Output (I-P-U) descriptions in English 2.Dataflow diagrams (DFD) 3.Entity Relations diagram (ERD) 4.Use Case Diagram from Unified Modeling Language (UML) Once the requirements are defined in detail using any of the above forms, they still need to be reviewed (see chapter 10 of your textbook) by the users/customers and other stakeholders.

22. English I/P/O : functionality, business and data flow

24. Captures - relations among data

26. 26 Using Object Oriented (OO) Use Case Methodology and Notation, which identifies: Basic/Main functionalities Pre-conditions of functionality Flow of events or scenarios Post-conditions for the functionality Error conditions and alternative flows Using OO Use Case Diagram which identifies: Actors (or all external interfaces with the system, including the users) Related “use cases” (major functionalities) Boundary conditions

27. 27 Capability to trace a requirements is needed to ensure that the product has fully implemented the requirements. (while not part of requirements process activities – it needs to be started early) We need to trace requirements: Requirements from source (people and documents) Requirements to later steps (design, implementation, test, & release) We also need to link requirements to other “pre-requisite” requirements.

28. 28 Requirements prototyping mostly address the User Interface (UI) part of the requirement in terms of: Visual looks (size, shape, position, color) Flow (control and logical flow; depth of flow) The prototyping may be performed in one of the two modes: Low fidelity : using paper/cardboard to represent screens and human to move the boards High fidelity : using automated tools such as Visual Basic to code the screens and direct the logical flow of these screens

29. 29 Once the requirements are defined, prototyped and reviewed, it must be placed into a Requirements Specification document IEEE /EIA Standard 12207.1-1997 outlines the guide for 3 major sections of a requirements specification document. Introduction High Level description Detailed descriptions o Details of each functionality (input-out-process) o Interfaces, including user interfaces and network interfaces o Performance requirements (response time, throughput, etc.) o Design constraints, standards, etc. o Additional attributes such as security, reliability, etc. o Any additional unique requirements Requirements Signoff -- Having a requirements specification agreed to and signed off is important: Serves as a milestone marker and formally exits a phase of software of engineering Serves as baseline from which any future changes can be monitored and controlled

30. 30 Having a requirements specification agreed to and signed off is important: Serves as a milestone marker and formally exits a phase of software of engineering Serves as baseline from which any future changes can be monitored and controlled

31. 31 Review Questions

32. 32 1. List and describe at a high level the steps involved in software requirements engineering process. Ans: Requirements engineering are composed of the following activities: elicitation analysis definition prototyping review specification agreement or sign-off (see figure 6.2) Page: 104 2. What are the three main items that must be planned prior to conducting requirements engineering? Ans: The three main items are: Requirements engineering process Resources needed Schedule of activities and completion date of requirements engineering Page: 104-106

33. 33 3. What are the six main dimensions of requirements that one needs to address when collecting requirements? Ans: The six main dimensions are: business flow data, formats, and information needs individual functionality system and other interfaces user interfaces constraints such as performance, security, quality, etc. Page: 110 (Figure 6.3) 4. List four items that are included in the description of high level business profile. Ans: The four items are any from the following list of six: opportunity and needs justification scope major constraints success factor user characteristics Page: 108-109

34. 34 5. List and describe three items that will need to be considered in prioritizing requirements. Ans: Possible answers are: Current customer demands Competition and current market condition Future customer needs Immediate sales advantage Critical problems in the existing product Page: 117 6. What is the Viewpoint-Oriented Requirements Definition (VORD) method used for? Ans: This method is based on the understanding that requirements are not viewed the same by the different stakeholders. So this methodology of collecting requirements ensures that all different perspectives of requirements are provided. Page: 116-117

35. 35 7. Consider the situation where you have the following four requirements for an employee information system: Response time for short queries must be less than 1 sec. In defining employee record, user must be able to enter employee name and be prompted for all the remaining employee attributes that are needed for the employee record. Employee information may be searched using either the employee number or employee’s last name. Only authorized (employee himself, managers in his/her chain of command, personnel) search will show employee salary, benefits, and family information. Perform Analytical Hierarchy Process and rank these based on your choices. Ans: Assume the following pair-wise relationship: Page: 118-119 Req 1 Req2 Req3 Req4 Req 1 1 3 5 2 Req2 1/3 1 2 2 Req3 1/5 ½ 1 4 Req4 ½ ½ ¼ 1 ----------------------------------------------------------- Sum 2.03 5.0 8.25 9 The normalized table is formed by dividing each element by the columns sum: Req 1 Req2 Req3 Req4 Sum Req 1.49.6.6.22 1.91 Req2.16.2.24.22.82 Req3.09.1.12.44.75 Req4.24.1.03.11.48 Req 1: 1.91/4 =.4775 Req 2:.205 Req 3:.187 Req 4:.12 So these requirements 1 through 4 turn out to be in that exact order in priority.

36. 36 8. Express in E-R diagram the relationship between programmers and modules where a programmer may write several modules and each module may also be written by several programmers. Ans: Page: 121-123 What are the four types of requirements traceability? Ans: Four types of traceability are: Backward from traceability: Links the requirement to the document source or the person who created it. Forward from traceability: Links the requirement to design and implementation. Backward to traceability: Links design and implementation back to the requirements. Forward to traceability: Links documents preceding the requirements to the requirements. Page: 120