Requirements - 1.

Requirements - 1

Software Development Activities
Requirements Elicitation Requirements Analysis System Design Object Design Implemen- tation Testing Implemented By Expressed in Terms Of Structured By Realized By Verified By class... ? class.... ? Application Domain Objects Use Case Model Implementation Domain Objects SubSystems Source Code Test Cases

Types of Projects Greenfield Engineering Re-engineering
Development starts from scratch, no prior system exists, the requirements are extracted from the end users and the client Re-engineering Re-design and/or re-implementation of an existing system using newer technology Interface Engineering Resign of the user interface of an existing system

Requirements Elicitation
Challenging activity Requires collaboration of people with different backgrounds User has application domain knowledge Developer has implementation domain knowledge Define the system Easy to define (and then solve) the wrong problem

Requirements Process Requirements Elicitation Analysis
Definition of the system in terms understood by the customer Analysis Technical specification of the system in terms understood by the developer.

Products of Requirements Process
Elicitation analysis model :Model system specification Analysis

System Specification vs Requirements Analysis Model
Both focus on the requirements from the user’s view of the system. System specification uses natural language (derived from problem statement) Requirements analysis model uses formal or semi-formal notation (e.g., UML)

Types of Requirements Functional requirements: Describe the interactions between the system and its environment independent from implementation The watch system must display the time based on its location

Types of Requirements Nonfunctional requirements: User visible aspects of the system not directly related to functional behavior. The response time must be less than 1 second The accuracy must be within a second The watch must be available 24 hours a day except from 2:00am-2:01am and 3:00am-3:01am

Types of Requirements Constraints (“Pseudo requirements”): Imposed by the client or the environment in which the system will operate The implementation language must be JAVA. Must interface to the dispatcher system written in 1956.

Requirements Elicitation Activities
Identify actors Identify scenarios Identify use cases Identify relationships among use cases Refine use cases Identify nonfunctional requirements Identify participating objects

Actors What’s an ACTOR? How do we identify them?
An external entity that interact with the system Can be human or an external system How do we identify them? Which user groups are supported by the system to perform their work Which user groups execute the system’s main function? Which user groups perform secondary function, such as maintenance and administration? Will the system interact with any external hardware or software system? The choice of actors helps us to define the system boundary, and the system boundary helps us to identify the actors

Example: SatWatch SatWatch is a wrist watch that displays the time based on its current location. It uses GPS satellites to determine its location and internal data structures to convert this location into a time zone. Satwatch adjusts the time and date displayed as the watch owner crosses time zones and political boundaries (e.g., standard time vs. daylight savings time) When a new country or institutes different rules for daylight saving time, the watch owner may upgrade the software of the watch using the WebifyWatch serial devices and a personal computer connected to the Internet. SatWatch complies with the physical electrical, and software interfaces defined by WebifyWatch API2.0.

Tools Bridging the gap between user and developer … Scenario:
Example of the use of the system in terms of a series of interactions between the user and the system Concrete / Real / Phenomenon Use case: Abstraction that describes a class of scenarios Concept

Scenarios “A narrative description of what people do and experience as they try to make use of computer systems and applications” [M. Carrol, Scenario-based Design, Wiley, 1995] A concrete, focused, informal description of a single feature of the system used by a single actor. Scenarios can have many different uses during the software lifecycle

Types of Scenarios As-is scenario Visionary scenario
Used in describing a current situation. Usually used during re-engineering. The user describes the system. Visionary scenario Used to describe a future system. Usually described in greenfield engineering or reengineering. Often can not be done by the user or developer alone Can be viewed as an inexpensive prototype

Types of Scenarios Evaluation scenario Training scenario
User tasks against which the system is to be evaluated Training scenario Step by step instructions designed to guide a novice user through a system

Heuristics for finding Scenarios
Ask yourself or the client the following questions: What are the primary tasks that the system needs to perform? What data will the actor create, store, change, remove or add in the system? What external changes does the system need to know about? What changes or events will the actor of the system need to be informed about?

Heuristics for finding Scenarios
Insist on task observation if the system already exists (interface engineering or reengineering) Ask to speak to the end user, not just to the software contractor Expect resistance and try to overcome it

Scenario Example: Warehouse on Fire
Bob is driving down main street in his patrol car and notices smoke coming out of a warehouse. His partner, Alice, reports the emergency from their car. Alice reports the address of the building, a brief description of its location (i.e., north west corner), and an emergency level. In addition to a fire unit, she requests several paramedic units on the scene given that area appear to be relatively busy. She confirms her input and waits for an acknowledgment.

Scenario Example: Warehouse on Fire (continued)
John, the Dispatcher, is alerted to the emergency by a beep of his workstation. He reviews the information submitted by Alice and acknowledges the report. He allocates a fire unit and two paramedic units to the Incident site and sends their estimated arrival time (ETA) to Alice. Alice receives the acknowledgment and the ETA.

Observations about Warehouse on Fire Scenario
Concrete scenario Describes a single instance of reporting a fire incident. Does not describe all possible situations in which a fire can be reported. Participating actors Bob, Alice and John

Next goal, after the scenarios are formulated:
Find a use case in the scenario that specifies all possible instances of how to report a fire Example: “Report Emergency “ in the first paragraph of the scenario is a candidate for a use case Describe this use case in more detail Describe the entry condition Describe the flow of events Describe the exit condition Describe exceptions Describe special requirements (constraints, nonfunctional requirements)

Example of steps in formulating a use case
First name the use case Use case name: ReportEmergency Then find the actors Generalize the concrete names (“Bob”) to participating actors (“Field officer”) Participating Actors: Field Officer (Bob and Alice in the Scenario) Dispatcher (John in the Scenario) ? Then concentrate on the flow of events Use informal natural language

Formulate the Flow of Events (Figure 4-7): The FieldOfficer activates the “Report Emergency” function on her terminal. FRIEND responds by presenting a form to the officer. The FieldOfficer fills the form, ... The FieldOfficer also describes possible responses to the emergency situation. Once the form is completed, the FieldOfficer submits the form, … The Dispatcher reviews the submitted information and creates an Incident in the database by invoking the OpenIncident use case. The Dispatcher … The FieldOfficer receives the acknowledgment and the selected response.

Write down the exceptions: The FieldOfficer is notified immediately if the connection between her terminal and the central is lost. The Dispatcher is notified immediately if the connection between any logged in FieldOfficer and the central is lost. Identify and write down any special requirements: The FieldOfficer’s report is acknowledged within 30 seconds. The selected response arrives no later than 30 seconds after it is sent by the Dispatcher.

How to Specify a Use Case (Summary)
Name of Use Case Actors Description of actors involved in use case Entry condition Use a syntactic phrase such as “This use case starts when…” Flow of Events Free form, informal natural language Exit condition Start with “This use cases terminates when…” Exceptions Describe what happens if things go wrong Special Requirements List nonfunctional requirements and constraints

Use Case Model for Incident Management
Dispatcher FieldOf f icer OpenIncident ReportEmergency AllocateResources

Why use cases work Utterly comprehensible by the user
Use cases model a system from the users’ point of view (functional requirements) Define every possible event flow through the system Description of interaction between objects Great tools to manage a project. Use cases can form basis for whole development process User manual System design and object design Implementation Test specification Client acceptance test An excellent basis for incremental & iterative development

Requirement– 2

Use Case Associations Developing a Use Case model involves breaking up use cases in search of simpler ones Use case association = relationship between use cases Three types supported in UML: Extends Include Generalization (not in text)

Extend A base use case implicitly includes the behavior of another use case at one or more extension points Generally used to factor out behavior that is optional or occurs only under certain conditions E.g. alternate or exceptional cases Exception case Normal case <<extend>>

<<extend>>
Check Order Status <<extend>> Cancel Order E.g. In the course of checking on the status of an order, the user finds that the item ordered won’t be in stock for 2 months. The user decides to cancel the order.

Include One use case explicitly includes the behavior of another use case at a specified point within a course of action Useful in factoring out behavior that would otherwise occur in multiple use cases Base case Included case <<include>>

<<include>>
View account <<include>> Login Place order <<include>>

Generalization Parent use case defines behavior that the child use cases can inherit and override Similar to inheritance in classes Parent Use Case Child Use Case

Generalization Perform Search Search by Title Search by Author
Search by Date

How do I find use cases? Select a narrow vertical slice of the system (i.e. one scenario) Discuss it in detail with the user to understand the user’s preferred style of interaction Select a horizontal slice (i.e. many scenarios) to define the scope of the system. Discuss the scope with the user Find out what the user does Task observation (Good) Questionnaires (Bad) Draw and revise use case diagram Discuss with the user

From Use Cases to Objects
Le v el 1 Top Level Use Case Le v el 2 Le v el 2 Level 2 Use Cases Le v el 3 Le v el 3 Le v el 3 Level 3 Use Cases Operations Le v el 4 Le v el 4 A B Participating Objects

Finding Participating Objects in Use Cases
Find terms that developers or users need to clarify in order to understand the flow of events Identify real world entities that the system needs to keep track of. Examples: FieldOfficer, Dispatcher, Resource

Finding Participating Objects in Use Cases
Identify real world procedures that the system needs to keep track of. Example: EmergencyOperationsPlan Identify data sources or sinks. Example: Printer Identify interface artifacts. Example: PoliceStation Do textual analysis to find additional objects (Use Abott’s technique) Model the flow of events with a sequence diagram

Abbott’s Heuristics

Identifying Nonfunctional Requirements -1
User interface and human factors What kind of interface? What’s the level of user expertise? Documentation What level of documentation Hardware considerations Hardware compatibility, interaction with other hardware system Performance characteristics How responsive? How many concurrent users should it support? Error handling and extreme conditions Which exception should be handled? How? What’s the worst environment in which the system is expected to perform?

Identifying Nonfunctional Requirements
Quality issues How reliable/available/robust? System modifications Anticipated scope of future change? Who will perform change? Physical environment Where will the system be deployed? Weather condition? Security issues Should the system be protected against external intrusions? Resource issues Constraints on resource

Analysis - (1) Analysis

Overview of Analysis Formalize the specification produced during requirements elicitation Developers build a model of the application domain What are the objects? What are their attributes? How do the actors and the system interact? Why do we call it ANALYSIS? Define analysis

Analysis 1. A separating or breaking up of any whole into its parts so as to find out their nature, proportion, function, relationship, etc. Webster’s New World Dictionary

Products of requirements elicitation and analysis
System Design system model :Model system specification analysis model Requirements Elicitation Analysis

The Analysis Model analysis model:Model dynamic object functional
use case diagram:View class statechart sequence

UML: Class and Instance Diagrams
Inspector Class Diagram joe: Inspector mary: Inspector anonymous: Inspector Instance Diagram

Analysis Concepts Types of objects modeled in analysis
Entity Boundary Control Associations used in analysis model Multiplicity Aggregation Generalization

Analysis Objects Entity Boundary Control
Persistent information tracked by the system Correspond to the nouns in the uses cases E.g. Book Boundary An object with which the actor of a use case interacts with the system (e.g., form) Control Represent the tasks performed by the user and supported by the system E.g. Display (verb)

Analysis Objects Why the three types?
Results in smaller and more specialized objects Leads to models that are more resilient to change Interface most likely to change Will help with sequence diagrams Control objects serve as “connecting tissue” between users and stored data Object types originated in Smalltalk: Model, View, Controller (MV)

Example: 2BWatch Objects
UML provides the stereotype mechanism to present new modeling elements stereotype is a string enclosed by angle brackets, which is attached to a UML element, such as a class or an association It enables modelers to create new kinds of building blocks that are needed in their domain Use naming convention: suffix “Control”, “Boundary” <<entity>> Year Month Day <<control>> ChangeDateControl <<boundary>> LCDDisplayBoundary ButtonBoundary

1-to-1 and 1-to-many Associations
Country name:String City name:String Has-capital One-to-one association Workorder schedule() StickyNote * x: Integer y: Integer z: Integer One-to-many association

Object Instance Diagram
Example for 1-to-many :Sticky x,y,z=(-1,0,5) :WorkOrder :Sticky x,y,z=(1,10,1) :Sticky x,y,z=(10,1,2)

Many-to-Many Associations
Mechanics Plane * Work on *

Aggregation Models "part of" hierarchy
Useful for modeling the breakdown of a product into its component parts UML notation: uses a small diamond to indicate the assembly end of the relationship.

Aggregation weight Automobile serial number year manufacturer model
color drive purchase Engine horsepower volume on off 1 3,4,5 2,4 1 * Wheel diameter number of bolts Brakelight on off Door open close Battery amps volts charge discharge

Inheritance Models "kind of" hierarchy
Powerful notation for sharing similarities among classes while preserving their differences UML Notation: An arrow with a triangle Cell MuscleCell BloodCell NerveCell Striate Smooth Red White Pyramidal Cortical

Aggregation vs Inheritance
Both associations describe trees (hierarchies) Aggregation tree describes a-part-of relationships Inheritance tree describes "kind-of" relationships Aggregation relates instances (involves two or more different objects) Inheritance relates classes (a way to structure the description of a single object)

Example: Hierarchical File System
Directory FileSystemElement File 1 * A Directory can contain any number of FileSystemElements (a FileSystemElement is either a File or a Directory). A given FileSystemElement, however, is part of exactly one Directory.

Example: Nonhierarchical file system
Directory FileSystemElement File * A Directory can contain any number of FileSystemElements (a FileSystemElement is either a File or a Directory). A given FileSystemElement can be part of many Directory (ies).

Analysis Activities Identifying entity objects
Identifying boundary objects Identifying control objects Mapping use cases to objects Identifying associations among objects Identifying object attributes Modeling nontrivial behavior with statecharts Modeling generalization relationships Reviewing the analysis model

Identifying Boundary Objects
System interfaces with actors Collect information from the actor and translate it into a form that can be used by other objects in the system Use a coarse level Allows the interface to change without having to change the analysis model

Heuristics for identifying boundary objects
Identify data entry forms/windows (e.g. EmergencyReportForm, ReportEmergencyButton) Identify messages system sends to user (e.g., AcknowledgementNotice) Do not model visual aspects of the system – use mock-ups or prototypes Use the user’s terms as opposed to implementation terms

Identifying Control Objects
Coordinate between boundary and entity objects Usually do not have a real world counterpart Relate closely to use case Responsible for collecting information from boundary objects and relaying it to entity objects

Heuristics for identifying control objects
Identify a small number of control objects per use case. Each flow of events should have a control object. Identify a control object for each actor A control object should exist for only one use case. (Its lifespan should be just one use case.)

Example: Login to Internet Bookstore
Actor: Customer Use case - flow of events The customer clicks the login button on the home page. The system displays the login page. The customer enters his/her user ID and password and clicks the OK button. The system validates the login information against the accounts data. The system returns the customer to the home page.

Entity objects Customer Account Boundary Objects Home page Login page Buttons? Control Objects Display

Object Modeling Main goal: Find the important abstractions
Steps during object modeling 1. Class identification 2. Find the attributes 3. Find the methods 4. Find the associations between classes Order of steps Goal: get the desired abstractions Order of steps secondary, only a heuristic Iteration is important

How do you find classes? Learn about problem domain: Observe your client Apply general world knowledge and intuition Take the flow of events and find participating objects in use cases Do a textual analysis of scenario or flow of events (Abbott Textual Analysis, 1983) Nouns are good candidates for classes Apply design patterns (later) Try to establish a taxonomy

Example: Scenario from Problem Statement
Jim Smith enters a store with the intention of buying a toy for his 3 year old child. The store owner gives advice to the customer. The advice depends on the age range of the child and the attributes of the toy. Jim selects a dangerous toy which is unsuitable for the child. The store owner recommends a safer doll. Note: Help must be available within less than one minute.

Abbot’s Heuristics Part of speech Model component Example Proper noun
object Jim Smith Improper noun class Toy, doll Doing verb method Buy, recommend being verb inheritance is-a (kind-of) having verb aggregation has an modal verb constraint must be adjective attribute 3 years old transitive verb enter intransitive verb method (event) depends on

Object Modeling in Practice: Class Identification
Foo Balance CustomerId Deposit() Withdraw() GetBalance() Class Identification: Name of Class, Attributes and Methods

Object Modeling in Practice: Encourage Brainstorming
Money Balance CustomerId Deposit() Withdraw() GetBalance() Foo Balance CustomerId Deposit() Withdraw() GetBalance() Account Balance CustomerId Deposit() Withdraw() GetBalance() Naming is important!

Object Modeling in Practice
Account Balance Deposit() Withdraw() GetBalance() Customer Name Bank Name AccountId CustomerId Find New Objects Iterate on Names, Attributes and Methods

Associations Class diagrams describe spatial connectivity of objects
Can include associations to show relationships Properties of associations name: e.g. has, reports to, contains role of each class multiplicity

Roles A role name is the name that uniquely identifies one end of an association. A role name is written next to the association line near the class that plays the role. When do you use role names? Necessary for associations between two objects of the same class Also useful to distinguish between two associations between the same pair of classes When do you not use role names? If there is only a single association between a pair of distinct classes, the names of the classes serve as good role names

Example of Role Problem Statement : A
person assumes the role of repairer with respect to another person, who assumes the role of inspector with respect to the first person. Person Person Creates Workorders Person inspector Person Creates Workorders repairperson

Qualification The qualifier improves the information about the multiplicity of theassociation between the classes. It is used for reducing 1-to-many multiplicity to 1-1 multiplicity Without qualification: A directory has many files. A file belongs only to one directory. Directory File filename 1 * 0..1 With qualification: A directory has many files, each with a unique name

Example Pr oblem Statement : A stock exchange lists many companies.
However , a stock exchange lists only one company with a given ticker symbol. A company may be listed on many stock exchanges, possibly with different ticker symbols. Find company with ticker symbol AAPL. StockExchange Company tickerSym * lists

Use of Qualification reduces multiplicity
StockExchange Company tickerSym * StockExchange 1 0..1 Company tickerSym

Object Modeling in Practice
Account Balance AccountId Deposit() Withdraw() GetBalance() Customer Name CustomerId * Bank Name Has Find New Objects Iterate on Names, Attributes and Methods Find Associations between Objects Label the associations Determine the multiplicity of the associations

Object Modeling in Practice: Categorize!
Account Balance AccountId Deposit() Withdraw() GetBalance() Customer Name Bank * * Name Has CustomerId Savings Account Checking Account Mortgage Account Withdraw() Withdraw() Withdraw()

Object Modeling in Practice: Heuristics
Explicitly schedule meetings for object identification Try to differentiate between entity, boundary and control objects Find associations and their multiplicity Unusual multiplicities usually lead to new objects or categories Identify Aggregation Identify Inheritance: Look for a Taxonomy, Categorize Allow time for brainstorming - Iterate, iterate, iterate

Analysis – (2) Analysis

The Analysis Model analysis model:Model dynamic object functional
use case diagram:View class statechart sequence

Analysis Activities Identifying entity objects
Identifying boundary objects Identifying control objects Mapping use cases to objects Identifying associations among objects Identifying object attributes Modeling nontrivial behavior with statecharts Modeling generalization relationships Reviewing the analysis model

(UML activities diagram).
Analysis activities (UML activities diagram).

Modeling Interactions Between Objects
Sequence diagrams tie use cases and objects together Objects that participate in use case form columns Vertical dashed line is called the lifeline Time progresses from top to bottom Horizontal arrows represent messages sent from one object to another Rectangles represent the activation of an operation

Example Sequence Diagram

Heuristics for drawing sequence diagrams
Actor who initiates – on the left Next - the boundary object that the actor uses to initiate Next – the first use case control object Boundary objects are created by control objects Entity objects are accessed by control objects and boundary objects Entity objects should NOT access boundary or control objects (WHY?)

Actor: Customer Use case - flow of events The customer clicks the login button on the home page. The system displays the login page. The customer enters his/her user ID and password and clicks the OK button. The system validates the login information against the account’s data. The system returns the customer to the home page.

Entity objects Customer? Account Boundary Objects Home page Login page Buttons? Control Objects Display

Login Sequence Diagram
Initiating actor? Boundary object that actor uses in initiation? Control object? Messages? Use Together to generate Follow heuristics

Why Use Sequence Diagrams?
Model the order of interactions of objects Side effect: May result in rewriting the flow of control for a use case in more precise terms Distribute the behavior of the use case among the objects (design) Forces us to start thinking about the methods of an object Identify missing behavior acts as a check Forces us to focus and think more critically

Is it worth the effort? Time consuming Difficult
May not want to do for simple parts of system Although we learn from doing simple parts There are other tools that are used to allocate behavior e.g. CRC cards

Collaboration Diagrams
Sequence diagrams and collaboration diagrams belong to the general class of interaction diagrams Capture the same content Can be converted automatically to the other style Collaboration diagram is more free-form Does not emphasize time ordering Convert sequence diagram to collaboration in Together.

Statechart Diagrams Graph whose nodes are states and whose directed arcs are transitions labeled by event names. A statechart diagram relates events and states for one class An object model with a set of objects has a set of state diagrams A state diagram relates events and states for one object. A transition is drawn from State diagrams would be quite useless if they only describe event patterns. A behavioral description of an object must specify what the object does in response to events. This is specified in operations attached to states and transition . An activity is an operation that takes time to complete. Activities are always associated with a state. The notation do Activity1 within a state box indicates that activity A start on entry to the state and stops when complete. Sometimes it is more advantageous to associate an action with a state. When? When all the state transitions cause the same action, it is a better notational convenience to list the action only once. This reduces clutter in the state diagrams. An action is an instantaneous operation. This is of course a relative notion. What we mean by instantaneous is that the duration of the operation is insignificant when compared to the time resolution of the state diagram. It also means we do not care about the internal structure of this operation. An action is therefore associated with an event.

State An abstraction of the attribute of a class
State is the aggregation of several attributes of a class Basically an equivalence class of all those attribute values and links that do no need to be distinguished as far as the control structure of the system is concerned Example: State of a bank A bank is either solvent or insolvent State has duration An object model describes the possible patterns of objects, attribute values and links that can exist in a system. A dynamic model describes the possible patterns of states, events and actions that can exist in a system. Over time, the objects stimulate each other, resulting in a series of changes to their states. An individual stimulus from one object to another is called an event. Events can be organized into classes. Events can be error conditions as well as normal occurences. Event as an object : Some events are only signals (OK), others have attributes associated with them (Unix signals: Bus error, Segment violation). Attributes are shown in parentheses after the class name. Events are important for UI, Communication and Notification. Other groups have to worry about events as well, because the interaction between the subsystems should be via the Request Broker. The response to an event depends on the state of the object receiving it. It can include a state change or sending of another event to another object and sending a event back to the sender (return result, ok, ...) The Events and states are duals of one another: An event separates 2 states and a state separates 2 events.

UML Statechart Diagram Notation
Event trigger With parameters State1 State2 Event1(attr) [condition]/action do/Activity Guard condition entry /action exit/action A state is drawn as a rounded box containing a name. The state name appears in bold face A transition is drawn as an arrow from the receiving state to the target state. Event names are written on the transition arrow, optionally followed by one or more attributes within parentheses. A condition is a Bollean function of object values, such as emission is above legal value. Conditions can be guards on transitions. A guarded transition fires only when the event occurs and the condition is true. Conditions are shown as expressions in square brackets following the event name and its parameter list. An action follows the event name and/or the condition by the slash (/) character. Events that cause an action without causing a state change are written inside the state box. Internal action and self-transition are different. When an internal action occurs, neither the entry nor exit action is executed, when a self-transition occurs, these actions are executed. Events sent to other objects are shown in dashed lines. A UML statechart diagram can be mapped into a finite state machine

UML statechart for Incident.
numAllocatedResource == 0 all reports when incident.date > 1yr. are submitted Active Inactive Closed Archived

Statechart diagram for 2Bwatch
MeasureTime SetTime pressButtonsLAndR pressButtonsLAndR/beep after 2 min. DeadBattery after 20 years

(UML activities diagram).
Analysis activities (UML activities diagram).

Reviewing the Analysis Model
Analysis model built incrementally and iteratively omission discovered during analysis may lead to new use case E.g. What happens to student applications after students have been selected for a term? Do we need an archive or purge applications use case? Reviews conducted to ensure that the necessary attributes are met Text lists a number of questions to ask…

Model Correct? Is the glossary of entity objects understandable by the user? Do abstract classes correspond to user-level concepts? Are all descriptions in accordance with users’ definitions? Do all use cases and control objects have meaningful verb phrases as names? Etc.

Model Consistent? Are there multiple classes or use cases with the same name? Do entities (e.g. use cases, classes, attributes) with similar names denote similar phenomena? Are all entities described at the same level of detail?

Model Realistic? Are there any novel features of the system? Were any studies or prototypes built to ensure their feasibility? Can the performance and reliability be met? Etc.

Managing Analysis Documenting Assigning Responsibilities Communicating
Client Sign-off

Requirements Analysis Document Template
1. Introduction 2. Current system 3. Proposed system 3.1 Overview 3.2 Functional requirements 3.3 Nonfunctional requirements 3.4 Constraints (“Pseudo requirements”) 3.5 System models 3.5.1 Scenarios 3.5.2 Use case model 3.5.3 Object model Data dictionary Class diagrams 3.5.4 Dynamic models 3.5.5 User interfae 4. Glossary

Documenting Analysis RAD documents both requirements elicitation and analysis activities Many sections written during requirements elicitation Those sections are reviewed and revised New sections are added Object models Dynamic models User interface: screen mockups, forms

Object Models Document the domain objects identified Attributes
As complete as possible No data types needed Operations From sequence diagrams List may be incomplete No logic Class diagrams showing relationships Data Dictionary with text descriptions

Dynamic Models Statechart diagrams for complex behavior of objects
Sequence diagrams for use cases Although they contain redundant information (have textual flow of events with use cases) useful because they are more precise and will help the designers understand the system

Assigning Responsibilities
Analysis involves many individuals User and client Analyst, architect, document editor, configuration manager, reviewer Challenging to coordinate and communicate Assign types of roles: Generation of information Integration Review

User and Client User Client Domain expert
Generates information about the current system and about the tasks that the future system should support Corresponds to one or more actors Helps identify their use cases Client Integration of user requests Defines the scope of the system based on (sometimes conflicting) user requirements

Analyst and Architect Analyst Architect Development domain expert
Models current system Generates information about the future system Architect Integrates the use case and object models Ensures consistency and completeness Develops system philosophy

Editor, Reviewer, Configuration Manager
Integration of document Format of document Reviewer Validates document against requirements qualities Configuration Manager Maintains revision history Coordinates traceability with other documents

Communicating Challenges Guidelines Different backgrounds
Different expectations Passing information to new teams Evolving system Guidelines Define clear territories Define clear objectives and success criteria Brainstorm

Client Sign-off Acceptance of the analysis model (RAD) by client
Also client and developer must agree on: Priorities Criteria by which to accept or reject system Schedule Budget Revision process

Example of a revision process

Requirements - 1.

Similar presentations

Presentation on theme: "Requirements - 1."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Requirements - 1.

Similar presentations

Presentation on theme: "Requirements - 1."— Presentation transcript:

Similar presentations

About project

Feedback