1. Requirements Analysis Scenes
Video Case Study
Video Case Study Module Number: VS01
This course material was developed with NSF – TUES award #

2. Project Engineering Hierarchy
Requirements engineering
world view
Component engineering
domain view
Analysis and Design modeling
element view (software engineers)
Construction and Integration
detailed view (software engineers)

3. Business Process Engineering Hierarchy
Information Strategy Planning
world view
Business Area Analysis
domain view
Business System Design
element view (software engineers)
Construction and Integration
detailed view (software engineers)

4. Requirements Analysis
Software engineering task bridging the gap between system requirements engineering and software design.
Provides software designer with a model of:
system information
function
behavior
Model can be translated to data, architectural, and component-level designs.
Expect to do a little bit of design during analysis and a little bit of analysis during design.

5. Analysis Objectives Identify customer’s needs.
Evaluate system for feasibility.
Perform economic and technical analysis.
Allocate functions to system elements.
Establish schedule and constraints.
Create system definitions.

6. Feasibility Study Economic feasibility Technical feasibility
cost/benefit analysis
Technical feasibility
hardware/software/people, etc.
Legal feasibility
Alternatives
there is always more than one way to do it

7. Requirements Engineering - 1
Requirements Elicitation
find out from customer
what the product objectives are
what is to be done
how the product fits into business needs
how the product is used on a day to day basis
Requirements Analysis
requirements organized into subsets
relations among requirements identified
requirements reviewed for correctness
requirements prioritized based on customer needs

8. Requirements Engineering - 2
Requirements Specification
work product produced describing:
function
performance
development constraints for system
System Modeling
system representation that shows relationships among the system components

9. Requirements Engineering - 3
Requirements Validation
examines the specification to ensure requirement quality
make sure work products conform to agreed upon standards
Requirements Management
set of activities that help project team to control and track requirements changes as project proceeds

10. Requirements Requirement
features of system or system function used to fulfill system purpose.
Focus on customer’s needs and problem, not on solutions:
Requirements definition document
(written for customer).
Requirements specification document
(written for programmer; technical staff).

11. Types of Requirements - 1
Functional requirements:
input/output
processing.
error handling.
Non-functional requirements:
Physical environment (equipment locations, multiple sites, etc.).
Interfaces (data medium etc.).
User & human factors (who are the users, their skill level etc.).

12. Types of Requirements - 2
Non-functional requirements (continued):
Performance (how well is system functioning).
Documentation.
Data (qualitative stuff).
Resources (finding, physical space).
Security (backup, firewall).
Quality assurance (max. down time, MTBF, etc.).

13. Software Requirements Elicitation
Customer meetings are the most commonly used technique.
Use context free questions to find out
customer's goals and benefits
identify stakeholders
gain understanding of problem
determine customer reactions to proposed solutions
assess meeting effectiveness
Interview cross section of users when many users are anticipated.

14. Requirement Validation
Correct?
Consistent?
Complete?
Externally - all desired properties are present.
Internally - no undefined references.
Each requirement describes something actually needed by the customer.
Requirements are verifiable (testable)?
Requirements are traceable.

15. Traceability Tables Features traceability table
Source traceability table
Dependency traceability table
Subsystem traceability table
Interface traceability table

16. Requirements Analysis Scenes
Case Study Video: Requirements Analysis Scenes
Developed by: Robert Morris University
What is this ?
The scenes in this video portray brief dramatizations in a requirements elicitation process.
The scenes present industry best practices and problems that can occur during the process.
The scenes also demonstrate appropriate and inappropriate conducts during Requirements Analysis process

17. Questions Prior to Video Display
What is a software requirement?
Who is responsible for providing the requirements for a software product
What is the role of a customer in a requirements elicitation process
What is the role of a practitioner in a requirements elicitation process

18. SCENE - 1

19. Video Case Study – SCENE 1
What is happening in this scene?
Do you think Mike is asking the right questions?
Do you think Yang is giving the right answers?
In a software project would both of them be project stakeholders?
What is the next step for Mike?

20. SCENE - 2

21. Video Case Study – SCENE 2
Is Mike using the right tools for this process?
Are the answers Yang giving adequate?
What are the attributes of good requirements?
Towards the end Mike looks amused. Why do you think this has happened?
What is the next step for Yang and Mike?

22. SCENE - 3

23. Video Case Study – SCENE 3
Is it okay for Mike to be amused?
How did Yang address Mike’s amusement?
Did the conversation between Yang and Mike happen in a professional manner? i.e. were the words used by Yang and Mike appropriate?
In a situation like this how should Yang, Mike, Raj behave?
Are the details in this conversation really necessary in this type of meeting?
Are the people in this scene adequate to identify requirements at this level?

24. SCENE - 4

25. Video Case Study – SCENE 4
Is it necessary that Mike and Yang discuss in such depth?
Are the people in this scene adequate to identify requirements at this level?
How did Mike help Yang think through his request for a Red Submit button?
What did Mike’s approach to helping Yang on his idea, tell you about Mike’s skills as a Business Analyst?

26. SCENE - 5

27. Video Case Study – SCENE 5
Are the details in this conversation really necessary in this type of meeting?
Are the two people in this scene adequate to identify requirements at this level?
What are some best design practices?
What are some good security practices?

28. Questions