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

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

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

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

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” ”

Why are Requirements Important? http://www.cs.cornell.edu/courses/cs501/2006sp/slides/ 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!

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.

Why is requirements engineering difficult? Answer? …

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

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

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.

Why is requirements engineering difficult? …

Why is requirements engineering difficult? …

Why is requirements engineering difficult? …

Why is requirements engineering difficult? …

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

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

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

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

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.

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.

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.

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

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

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

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

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

Introduction to UML Use Cases 29

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

Use Case Diagram

Depicting actors Payment Authorization Service

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

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

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

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.

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

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

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.

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

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

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

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:

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.

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

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

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

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

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

Summary 50

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

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

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

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

Introduction to UML Class Diagrams 55