Beruflich Dokumente
Kultur Dokumente
- Problems with requirements practices - Requirements engineering tasks - Inception - Elicitation - Elaboration - Negotiation - Specification - Validation - Requirements management
All of these arguments contain some truth, especially for small projects that take less than one month to complete However, as software grows in size and complexity, these arguments begin to break down and can lead to a failed software project
Some of these tasks may occur in parallel and all are adapted to the needs of the project All strive to define what the customer wants All serve to establish a solid foundation for the design and construction of the software
Inception Task
During inception, the requirements engineer asks a set of questions to establish
A basic understanding of the problem The people who want a solution The nature of the solution that is desired The effectiveness of preliminary communication and collaboration between the customer and the developer Identify the stakeholders Recognize multiple viewpoints Work toward collaboration Break the ice and initiate the communication
Who is behind the request for this work? Who will use the solution? What will be the economic benefit of a successful solution? Is there another source for the solution that you need?
How would you characterize "good" output that would be generated by a successful solution? What problem(s) will this solution address? Can you show me (or describe) the business environment in which the solution will be used? Will special performance issues or constraints affect the way the solution is approached?
Elicitation Task
Eliciting requirements is difficult because of
Problems of scope in identifying the boundaries of the system or specifying too much technical detail rather than overall system objectives Problems of understanding what is wanted, what the problem domain is, and what the computing environment can handle (Information that is believed to be "obvious" is often omitted) Problems of volatility because the requirements change over time
Elaboration Task
During elaboration, the software engineer takes the information obtained during inception and elicitation and begins to expand and refine it Elaboration focuses on developing a refined technical model of software functions, features, and constraints It is an analysis modeling task
Use cases are developed Domain classes are identified along with their attributes and relationships State machine diagrams are used to capture the life on an object
The end result is an analysis model that defines the functional, informational, and behavioral domains of the problem
Step Two Develop use cases, where each one answers a set of questions
Use-case Diagram
Class-based elements
Identify the domain classes for the objects manipulated by the actors, the attributes of these classes, and how they interact with one another; they utilize class diagrams to do this
Behavioral elements
Use state diagrams to represent the state of the system, the events that cause the system to change state, and the actions that are taken as a result of a particular event; can also be applied to each class in the system
Flow-oriented elements
Use data flow diagrams to show the input data that comes into a system, what functions are applied to that data to do transformations, and what resulting output data are produced
Negotiation Task
During negotiation, the software engineer reconciles the conflicts between what the customer wants and what can be achieved given limited business resources Requirements are ranked (i.e., prioritized) by the customers, users, and other stakeholders Risks associated with each requirement are identified and analyzed Rough guesses of development effort are made and used to assess the impact of each requirement on project cost and delivery time Using an iterative approach, requirements are eliminated, combined and/or modified so that each party achieves some measure of satisfaction
Specification Task
A specification is the final work product produced by the requirements engineer It is normally in the form of a software requirements specification It serves as the foundation for subsequent software engineering activities It describes the function and performance of a computer-based system and the constraints that will govern its development It formalizes the informational, functional, and behavioral requirements of the proposed software in both a graphical and textual format
Requirements traceability
Trace back to the system or subsystem where each requirement applies
Validation Task
During validation, the work products produced as a result of requirements engineering are assessed for quality The specification is examined to ensure that
all software requirements have been stated unambiguously inconsistencies, omissions, and errors have been detected and corrected the work products conform to the standards established for the process, the project, and the product
The formal technical review serves as the primary requirements validation mechanism
Members include software engineers, customers, users, and other stakeholders
Does the requirements model properly reflect the information, function, and behavior of the system to be built? Has the requirements model been partitioned in a way that exposes progressively more detailed information about the system?
Analysis Modeling
- Requirements analysis - Flow-oriented modeling - Scenario-based modeling - Class-based modeling - Behavioral modeling
35
A Set of Models
Flow-oriented modeling provides an indication of how data objects are transformed by a set of processing functions Scenario-based modeling represents the system from the user's point of view Class-based modeling defines objects, attributes, and relationships Behavioral modeling depicts the states of the classes and the impact of events on these states
36
Requirements Analysis
Purpose
Specifies the software's operational characteristics Indicates the software's interfaces with other system elements Establishes constraints that the software must meet Provides the software designer with a representation of information, function, and behavior
This is later translated into architectural, interface, class/data and component-level designs
Provides the developer and customer with the means to assess quality once the software is built
38
Overall Objectives
Three primary objectives
To describe what the customer requires To establish a basis for the creation of a software design To define a set of requirements that can be validated once the software is built
All elements of an analysis model are directly traceable to parts of the design model, and some parts overlap
39
Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the following
Information domain, function, and behavior of the system
The model should delay the consideration of infrastructure and other nonfunctional models until the design phase
First complete the analysis of the problem domain
The model should provide value to all stakeholders The model should be kept as simple as can be
40
Domain Analysis
Definition
The identification, analysis, and specification of common, reusable capabilities within a specific application domain Do this in terms of common objects, classes, subassemblies, and frameworks
41
Object-oriented analysis
Focuses on the definition of classes and the manner in which they collaborate with one another to fulfill customer requirements
42
Class-based modeling
Class diagrams Analysis packages CRC models Collaboration diagrams
Behavioral modeling
State diagrams Sequence diagrams
43
Flow-oriented Modeling
Data Modeling
Identify the following items
Data objects (Entities) Data attributes Relationships Cardinality (number of occurrences)
45
Process Specification
Describes data flow processing at the lowest level of refinement in the data flow diagrams
46
Guidelines
Depict the system as single bubble in level 0. Carefully note primary input and output. Refine by isolating candidate processes and their associated data objects and data stores. Label all elements with meaningful names. Maintain information conformity between levels. Refine one bubble at a time.
Grammatical Parse
The SafeHome security function enables the homeowner to configure the security system when it is installed, monitors all sensors connected to the security system, and interacts with the homeowner through the Internet, a PC, or a control panel. During installation, the SafeHome PC is used to program and configure the system. Each sensor is assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event occurs.
When a sensor event is recognized, the software invokes an audible alarm attached to the system. After a delay time that is specified by the homeowner during system configuration activities, the software dials a telephone number of a monitoring service, provides information about the location, reporting the nature of the event that has been detected. The telephone number will be redialed every 20 seconds until a telephone connection is obtained.
The homeowner receives security information via a control panel, the PC, or a browser, collectively called an interface. The interface displays prompting messages and system status information on the control panel, the PC, or the browser window. Homeowner interaction takes the following form
Level 1 diagram
Process Specification
53
Scenario-based Modeling
55
Cook
Customer
Pay for food and drink Pick up food and drink Attendant
56
Activity Diagrams
Creation of activity diagrams was previously described in Chapter 7 Requirements Engineering Supplements the use case by providing a graphical representation of the flow of interaction within a specific scenario Uses flowchart-like symbols
Rounded rectangle - represent a specific system function/action Arrow - represents the flow of control from one function/action to another Diamond - represents a branching decision Solid bar represents the fork and join of parallel activities
58
Swimlane diagram
Class-based Modeling
62
63
Retained information
Information must be remembered about the system over time Set of operations that can change the attributes of a class
Whereas, a single attribute may denote an atomic variable rather than a class
A set of attributes apply to all instances of a class A set of operations apply to all instances of a class Entities that produce or consume information
64
Usually an item is not an attribute if more than one of them is to be associated with a class
65
An operation has knowledge about the state of a class and the nature of its associations The action performed by an operation is based on the current values of the attributes of a class Using a grammatical parse again, circle the verbs; then select the verbs that relate to the problem domain classes that were previously identified
66
Attributes
Operations
Generalization
Portrays inheritance between a super class and a subclass Is represented by a line with a triangle at the target end
Dependency
A dependency exists between two elements if changes to the definition of one element (i.e., the source or supplier) may cause changes to the other element (i.e., the client) Examples
One class calls a method of another class One class utilizes another class as a parameter of a method
68
Identifying Classes
Potential class
homeowner sensor
Classification
role; external entity external entity
Accept / Reject
reject: 1, 2 fail accept
control panel
installation (security) system
external entity
occurrence thing
accept
reject accept
number, type
master password telephone number
reject: 3 fails
reject: 3 fails reject: 3 fails
sensor event
audible alarm monitoring service
occurrence
external entity organizational unit; ee
accept
accept: 1 fails reject: 1, 2 fail
Class Diagram
Class Diagram
CRC Modeling
Class Responsibilities
Distribute system intelligence across classes. State each responsibility as generally as possible. Put information and the behavior related to it in the same class. Localize information about one thing rather than distributing it across multiple classes. Share responsibilities among related classes, when appropriate.
Class Collaborations
Relationships between classes:
is-part-of used when classes are part of an aggregate class. has-knowledge-of used when one class must acquire information from another class. depends-on used in all other cases.
Class Diagrams
Behavioral Modeling
Identifying Events
A use-case is examined for points of information exchange. The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password in incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action.
State Diagram
Sequence Diagram