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

2. Agenda for Week 5 WebEx Practice MP1 Observations/Discussion
Chapter 6 Requirements
Use Case Review/Summary
Case Study 2 Discussion

3. WebEx Practice – In Class

4. MP1 Discussion

6. Requirements Engineering Definition & Preparation

7. Major Requirements Engineering Activities

8. Requirements Engineering Activities

9. Why is this set of activities important and why should requirements be documented? (remember Chaos Report?)
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

10. Requirements Elicitation
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

11. High Level Requirements Elicitation

12. Requirements Classification/Categorization
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

13. Requirements “Analysis/Categorization” of Multiple Views
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

14. Requirements Prioritization
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).

15. A Simple Requirements Prioritization List “sample”

16. Requirements Definition/Prototyping/Review
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

17. Requirements Definitions/Documentation
Requirements definitions may be written in different forms:
Simple Input/Process/Output (I-P-U) descriptions in English
Dataflow diagrams (DFD)
Entity Relations diagram (ERD)
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.

18. Requirement Definition using English and Input-Process-Output Diagram Form
English I/P/O : functionality, business and data flow

19. Requirements Definition using DFD4

20. Requirements Definition using Entity- Relation-Diagram (ERD)
Captures - relations among data

21. Requirements Definition Specifying Entity and Attributes

22. Requirements Analysis & Definition Methodology using UML
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

23. Requirements Traceability
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.

24. Requirements Prototyping
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

25. Software Requirements Specification (SRS)
Once the requirements are defined, prototyped and reviewed, it must be placed into a Requirements Specification document
IEEE /EIA Standard outlines the guide for 3 major sections of a requirements specification document.
Introduction
High Level description
Detailed descriptions
Details of each functionality (input-out-process)
Interfaces, including user interfaces and network interfaces
Performance requirements (response time, throughput, etc.)
Design constraints, standards, etc.
Additional attributes such as security, reliability, etc.
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

26. Finally --- Requirements “Sign Off”
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

27. Case Study 3

28. Case Study 3

29. Use Case Review/Summary

30. Use Case Diagram Symbols
A use case is a type of complete interaction between and product and its environment.
An actor is a type of agent that interacts with a product.
The collection of use cases characterizes all externally observable behavior.
A use case is an entire, coherent interaction.
Actors are roles not individuals.
The product is never an actor.
2010
2013/2016

31. Text Introduction to Use Cases Chap 9

32. Formation Rules Every use case diagram must have:
At least one use case
At least one actor
At least one actor associated with each use case
At least one use case associated with each actor
No association line between actors
No association line between use cases
Name every actor and use case
No association line label
Use Case Diagram Heuristics
Never make the product an actor.
Name actors with noun phrases.
Name use cases with verb phrases.
Achieve a stakeholder’s goal in a use case.
Make use cases that can be finished in a single session.
Make use cases of uniform size and complexity.
Draw use case diagrams on one page.
Organize use cases by actor, problem domain categories, or solution categories.

33. Case Study 2 Discussion

34. Case Study 2 Discussion

35. Summary
Review Questions

36. Chapter 6 Review Questions
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:

37. Chapter 6 Review Questions
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:

38. Chapter 6 Review Questions
 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:

39. Chapter 6 Review Questions
 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:
Req Req Req Req4
Req
Req /
Req / ½
Req ½ ½ ¼
Sum
The normalized table is formed by dividing each element by the columns sum:
Req Req Req Req Sum
Req
Req
Req
Req
Req 1: 1.91/4 = .4775
Req 2:
Req 3:
Req 4:
So these requirements 1 through 4 turn out to be in that exact order in priority.

40. Chapter 6 Review Questions
 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:
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