1. CSC450 Software Engineering
Devon M. Simmonds
University of North Carolina, Wilmington
Introduction to Requirements Engineering
Some slides adapted from slides created by Robert B. France

2. Outline The starting point Requirements engineering phases Scoping
What are requirements
Functional
Non-functional
UML Use Cases
Summary

3. Requirements Analysis
System Engineering
Software Lifecycle Activities
Software Design
Requirements Analysis
Implementation
System Engineering
Define software features
Testing
Deployment
Evolution
The Starting Point

4. Requirements Analysis
System Engineering
Software Lifecycle Activities
System Engineering
Requirements Analysis
Software Design
Implementation
Testing
Deployment
Evolution
Define software features

5. Requirements Engineering is Hard!
Your worst nightmare:
“A customer walks into your office, sits down, looks you straight in the eyes and says, “I know you think you understand what I said, but what you don’t understand is that what I said is not what I mean” ”

6. Why are Requirements Important?
Why are Requirements Important?
Causes of failed software projects (Standish Group study, 1994)
Incomplete requirements 13.1%
Lack of user involvement 12.4%
Lack of resources 10.6%
Unrealistic expectations 9.9%
Lack of executive support 9.3%
Changing requirements & specifications 8.8%
Lack of planning 8.1%
System no longer needed 7.5%
The commonest mistake is to build the wrong system!

7. Requirements Engineering?
System Analysis
Requirements Engineering
Software Design
Implementation
Testing
Deployment
Evolution
Define software features
The process of discovering, documenting and maintaining the tasks or functions the software should carry out.
The term “engineering” implies a systematic and repeatable process.

9. Why is requirements engineering difficult?
Answer? …

10. Why is requirements engineering difficult?
Spring 2011 Students
People change their minds
Technology change
Business rules change
Customer cannot describe what they want

11. Why is requirements engineering difficult?
Fall 2008 Students
Communication between client and developers
Unexpected requirements
Dependencies among requirements
Limited time stabilize requirements

12. Why is requirements engineering difficult?
Fall 2007 Students
Client explanation of problem is misinterpreted.
Communicating the requirements between client and development team is difficult.
Development team lacks domain experience.
Environment may change.

13. Why is requirements engineering difficult?…

14. Why is requirements engineering difficult?…

15. Why is requirements engineering difficult?…

16. Why is requirements engineering difficult?…

17. Foundations of requirements engineering
Cognitive psychology
Uncovering difficulties people have describing their needs.
Uncovering tacit knowledge of a domain expert
Mental modeling
Anthropology
A systematic approach to observing human behavior
Sociology
Understanding political and cultural changes/challenges caused by computerization
Linguistics
Understanding how to communicate unambiguously

18. Requirements Engineering
Focus on eliciting, analyzing, documenting and managing requirements for the software component of a system.
Elicitation
Analysis
Specification
Validation
Requirements
Management
Elicitation: extracting requirements from customers and users
Analysis: analyzing and organizing requirements to gain deeper understanding
Results of analysis reflected in models
Specification: detailed documentation of required behavior
Validation: requirements are validated against customer/user needs
Requirements management: activities related to documenting, controlling and tracking requirements and changes to requirements

19. Understanding the Context of a Software Application
Domain analysis : the process by which a software engineer learns about the domain to better understand the problem:
The domain is the general field of business or technology in which the clients will use the software
A domain expert is a person who has a deep knowledge of the domain
A domain model is created to describe some aspect of the domain

20. A Domain Model Does Not Represent Software Objects
A domain class model of a Video Store

21. What is a Domain Model? Structuring of domain concepts
Identifies problem concepts and their relationships
UML structural model used to depict structure
Key Question: What are the objects of interest in this domain?
their attributes?
their relationships?
IMPORTANT: This is a model of problem concepts; these concepts are NOT software objects, but a “visual dictionary” of domain concepts.

22. What is a software requirement?
A requirement is a statement about the proposed software that all stakeholders agree must be made true in order for the customer’s problem to be adequately solved.
Says something about what the software does and what data it maintains
All the stakeholders have agreed that it is valid
It helps solve the customer’s problem
A collection of requirements is a requirements document.

23. Requirements types Functional requirements Non-functional requirements
Describe what the system should do
Non-functional requirements
Constraints that must be adhered to during development
Examples:
the software must restrict access to sensitive information
the software must deliver a response within a time interval after a particular event has occurred
the software must be usable by persons who are not computer literate.

24. Non-Functional Requirements
Requirements that are not directly related to the functions that the system must perform
• Usability, documentation and training
• Reliability and quality assurance
• Performance
• Supportability
• Implementation and technical constraints
• Interfaces and compatibility
• Operation and physical environment
• Packaging and security
• Legal and business
• Resources

25. Describing Functional Requirements
What inputs the software should accept
What outputs the software should produce
What data the software should store that other systems might use
What computations the software should perform
What are the timing and synchronization of the above

26. Requirements Context Who is the application for?
Identify stakeholders (customers, end-users)
What problems will it solve?
Establish scope: determine features that will be in application and which will not
Where will it be used?
Determine whether application is mission-critical, experimental, or a non-disruptive new capability, etc.
Understand how the application will fit in with other systems
When is it needed?
Determine feasible time application can be developed and required time application is needed to meet business goals
Why is it needed?
Build a business case for the application
How will it work?
Brainstorm feasibility of solving the problem

27. Scoping Requirements Problem
Narrow the scope by defining a more precise problem
List all the things you might imagine the system doing
Exclude some of these things if too broad
Determine high-level goals if too narrow
Example: A university registration system

28. Key Requirements Models
Use Cases: Describe required functionality
Requirements Class Models: Identify problem concepts and their relationships
Technical/data dictionary: describes domain concepts

29. Introduction to UML Use Cases29

30. Requirements Use Cases
A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system – UML Specification
A use case model consists of
A set of use cases
An optional description or diagram indicating how they are related – a context model

31. Use Case Diagram

32. Depicting actors
Payment
Authorization
Service

33. Use Case Diagram Example
Update Benefits
UML 2.0 Use Case Terminology
A use case describes interactions between actors (clients) and a subject
At the requirements level the subject is the system under development
E.g. a system, a subsystem in a system, or a class

34. Online HR System: Update Benefits Use Case
Actors: employee, healthcare plan system, insurance plan system
Precondition:
Employee has logged on to the system and selected ‘update benefits’ option
Basic course
System displays employee account
System asks employee to select medical plan type; include Update Medical Plan.
System asks employee to select dental plan type; include Update Dental Plan. …
System asks user to select benefits options: benefit options
reimbursement option selected: Elect Reimbursement for Healthcare
stock option selected: Elect Stock Purchase

35. Another Example: Simple Item Rental Use Case
Actor Inputs
Customer submits identification information
3. Customer submits items to be rented
Customer pays.
System Response
2. If customer is authenticated, then request rental items
4. Display calculated price.
6. Inform customer that payments is authorized
Item Rental Use Case

36. Use Cases in UML: Core Elements
Both use cases and actors are classifiers.
An actor is a set of roles that a user of the system plays when interacting with the system.
An actor can be human, a hardware device, or another automated system
Example: For a Banking System, a person can play the role of a Loan Officer, and, if the person also has an account there, a Customer.
Actors are external to the system.
A use case describes a set of typical interactions between an external entity, called an actor, and the system.
The behavior described by a use case is the functionality of a system-level operation.
Example: For an ATM system, the withdraw cash operation can be described by a use case
Subject
The system under consideration to which the use cases apply, e.g. system, subsystem or class.

37. Use Cases as requirements
Use cases can be used to capture functional requirements
System attributes associated with a system operation can be documented in a use case
Not all requirements can be captured by use cases
System attributes that span use cases are documented as supplementary requirements

38. Actor types Primary: actor whose goal is accomplished by the use case
Supporting: actor that provides services to the system
E.g., authorization service
Offstage: an actor that has an interest in the use case but is not primary or supporting
E.g., regulating agency

39. Use Case instance (scenario)
A scenario is a particular sequence of actions in a use case.
A use case is a related set of scenarios that yields an observable result of value to a particular actor
A use case instance is an execution of a scenario.
A specific actor…
At a specific time…
With specific data
Often use case instance and scenario are used synonymously in informal discussions.

40. Levels of rigor Brief: One paragraph summaries of functionality
Casual: Multiple paragraphs that cover multiple scenarios
Fully-dressed (Detailed): Structured, detailed description of scenarios

41. Essential vs. Concrete Use Cases
Essential Use Cases describe functionality in implementation independent terms
Requirements level use cases must be essential
Concrete Use Cases describe external functionality in system dependent terms
Use cases can be used during design to document externally observable behavior of subsystems

42. Modeling and Describing Use Cases
Create the UML use case diagram
Describe
The activities performed for each use case
Many different formats available
UML does not specify a standard

43. Requirements Use Case template
Use Case Number:
EU-xxxx : Indicates an essential use case, i.e., a use case that describes activity in system independent terms
Use Case Name:
Enter name of Use Case.
Overview:
Describe the purpose of the Use Case and give a brief description.
Type:
Enter Use Case priority (primary, secondary, optional)
Actors:
List all actors that participate in this Use Case. Indicate the actor that initiates the use case by placing “initiator” in brackets after the actor name. Also, indicate primary actors by placing “primary” in brackets after actor name.
Properties:
Performance:
Security:
Other:

44. Analysis Use Case template – cont’d
Pre
condition:
Enter the condition that must be true when the main flow is initiated. This should reference the conceptual model.
Flow:
Main Flow: Steps should be numbered.
Subflows: Break down of main flow steps
Alternate Flows: Include the post condition for each alternate flow if different from the main flow.
Post Condition:
Enter the condition that must be true when the main flow is completed. This should reference the conceptual model. Include the following information in this section:
Cross References:
References to other Use Cases or textual requirements that relate to this Use Case.

45. Developing Use Cases
Continue here…
Scope system and identify primary actors that interact with the system
Determine goals of primary actors (can be documented in an Actor-Goal list)
For each actor, consider the ways that the actor typically interacts with the system to accomplish goals
Consider exceptional behaviors

46. Developing Use Cases: Identifying Use Cases and Actors
Approaches to identifying use cases
Actor-first: Identify actors first and consider the ways they interact with the system
Operation-first: Identify system-level operations and then identify actors that interact with operations
Event-first: Identify external events and develop use cases that handle the events

47. Exercise
Develop a use case diagram for a hotel management system.

48. The benefits of basing software development on use cases
They can help to define the scope of the system
They are often used to plan the development process
They can be used to both develop and validate the requirements
They can form the basis for the definition of test cases
They can be used to structure user manuals
They can be used during requirements to prototype user interfaces and during design to design user interfaces

49. Summary: use cases must not be seen as a panacea
The use cases must be validated
There are some aspects of development that are not covered by use case analysis.
Non-functional requirements are often not covered
Functionality that is not triggered by actors is not covered
E.g., auditing transactions in a banking system
There is a tendency to write use cases in terms of how a system works currently; this can bias design and make it less likely that designers will consider innovative solutions

50. Summary 50

51. Format of Requirements Specification?
See report format on course web page

52. Summary
Requirements engineering is an important component of software development
Addressing problems at the requirements stage reduces the cost of addressing the problems later
Requirements engineering will remain a difficult undertaking for the foreseeable future

53. Summary Qu es ti ons? What’s coming next class? ______________________
Devon M. Simmonds
Computer Science Department
University of North Carolina Wilmington
_____________________________________________________________

54. Other reasons requirements engineering is difficult?
Student answers (Spring 2007)
Users do not know what they want
Needs cannot be met
Weak problem solving skills

55. Introduction to UML Class Diagrams55