Escolar Documentos
Profissional Documentos
Cultura Documentos
Requirements (1)
_
_ _
What are requirements and why are they important? Problem frames Requirements elicitation Strategies
System & actor identification Use case & scenario analysis
Functional / non-functional requirements System / environment; software / process Requirements / preferences Stakeholders / viewpoints. Trade-offs / negotiation
Human-oriented issues
Understanding the systems context, reaching consensus, tracking issues, etc.
Engineering-oriented issues
Analytic methods, documentation quality, modeling, feasibility analysis, etc.
Co s t to fix
Well-understood requirements
Inconsistency
Unfeasibility Poor
writing
Expressed in Terms Of
Structured By
Source Code
Or textual requirements
Figure 4-1. Products of requirements elicitation and analysis (UML activity diagram).
Requirements Elicitation system specification :Model Analysis analysis model :Model
Both focus on the requirements from the users 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
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
Constraints (Pseudo requirements): Imposed by the client or the environment in which the system will operate
The implementation language must be COBOL. Must interface to the dispatcher system written in 1956.
System structure, implementation technology Development methodology Development environment Implementation language Reusability But descriptions of the real-world domains are in the requirements (even though they are not required)
Model
1 describes
System
*
Concept
* Phenomenon
Figure 4-2. A System is a collection of real world Phenomena. A Model is a collection of Concepts that represent the Systems Phenomena. Many Models can represent different aspects of the same System. An unambiguous Model corresponds to only one System.
Sys.
What well make the system do The way were assuming things will be
Sys.
Customer
Constructed domain
Appt. model is correct
Passage of time
Phone svc.
Controlled domain
_
_ _ _
Identify actors Identify scenarios Identify use cases Identify relationships among use cases Refine use cases Identify nonfunctional requirements Identify participating objects
Requirements Elicitation
_
Greenfield Engineering
Development starts from scratch, no prior system exists, the requirements are extracted from the end users and the client Triggered by user needs
Re-engineering
Re-design and/or re-implementation of an existing system using newer technology Triggered by technology enabler
Interface Engineering
Provide the services of an existing system in a new environment Triggered by technology enabler or new market needs
Blahing
Suppose a user called a mtg for next week. The system queries everyones online calendar and finds that there....
_
_ _
Scheduling a meeting without problems Someone remembers an appointment and cant attend Theres no convenient time Theres no venue available The notification mechanism breaks down Meeting bumped by CEO
Project definition
Research
Figure 4-12. Activities of JAD (UML activity diagram). The heart of JAD Preliminary specification is the Session activity during which all stakeholders design and Preparation agree to a system specification. The activities prior to the Session Session maximizes its efficiency. The production of the Working document Final document ensures that the decisions made during the Session are Scribe forms captured.
Session agenda
script
Session
Final document
System Identification
_
_ _
Development of a system is not just done by taking a snapshot of a scene (domain) Definition of the system boundary
What is inside, what is outside?
Use cases
_
Most systems have several major input events to which theyre supposed to respond
Ignore the subsidiary directives & additional inputs for now Major does not mean frequent
E.g. calling a meeting, canceling a meeting, becoming a new user of the system, remodeling rooms,...
dont forget these administrative/configuration use cases
Actors
_
Actors are
For example
Things that perform actions Either actors in the world Or actors in the machine
Figure 4-4. Actors of the FRIEND system. FieldOfficers not only have access to different functionality, they use different computers to access the system.
FieldOfficer
FRIEND
Dispatcher
Q: What is the context diagram for the PA system? Q1: How much is in the PA -v- its environment? Q2: Given that, what are the actors?
Dispatcher
OpenIncident
AllocateResources
Figure 4-8. Example of communication relationships among actors and use cases in FRIEND (UML use case diagram). The FieldOfficer initiates the ReportEmergency use case and the Dispatcher initiates the OpenIncident and AllocateResources use cases. FieldOfficers cannot directly open an incident or allocate resources on their own.
FieldOfficer ReportEmergency
ConnectionDown <<extend>>
Figure 4-9. Example of use of extend relationship (UML use case diagram). ConnectionDown extends the ReportEmergency use case. The ReportEmergency use case becomes shorter and solely focused on emergency reporting.
<<include>> OpenIncident
ViewMap <<include>>
AllocateResources
Figure 4-10. Example of include relationships among use cases. ViewMap describes the flow of events for viewing a city map (e.g., scrolling, zooming, query by street name) and is used by both OpenIncident and AllocateResources use cases.
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.
Types of Scenarios
_
As-is scenario
Used in describing a current situation. Usually used during reengineering. The user describes the system.
Visionary scenario
Used to describe a future system. Usually described in greenfield engineering or reengineering. Can often not be done by the user or developer alone
Evaluation 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
Why Scenarios?
_
Scenario Exploration
_
Scenario exploration is the process of understanding planned system behavior by walking through possibilities.
The goal may be just to get an idea of what the system will do and whether it is really needed.
Or it may be a more structured process: to evaluate alternative allocations by considering concrete behaviors that illustrate the interactions in each case.
Or considering the consequences of obstacles, and whether they are severe. Or considering the consequences of defending against or mitigating obstacles, and whether the costs are worth it.
Scenarios are Concrete Particular / Specific Selective with respect to salient situations Illustrative Compelling
When the initiator indicates completion of the definition of the meeting constraints, the system shall complete undefined constraints with default values and shall query the external calendar as follows....
Pointy-haired manager (PHM) wants to organize a meeting to discuss the drone-to-cube ratio and enters the names Dilbert and Wally as invitees and tomorrow by 5pm as latest time. The system queries the...
What is the appropriate level of detail for scenarios? How should scenarios be described and related to other software descriptions? esp. existing architecture Which are the right scenarios to explore?
Many design teams find it useful to give instances of actors, actions and data
Pointy-haired manager, not initiator Dilbert, Wally & PHM, not invitees Tomorrows cube mtg, not the meeting
Useful when
Communicating with non-technical customers Design team has dangerously little domain knowledge Scenarios are well-chosen, not just cute
Dont expect the client to be verbal if the system does not exist (greenfield engineering) Dont wait for information even if the system exists Engage in a dialectic approach (evolutionary, incremental)
You help the client to formulate the requirements The client helps you to understand the requirements The requirements evolve while the scenarios are being developed
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
Clear, precise
When PQR, the system shall XYZ
What
Making a vague statement more precise Saying what the system should do vs. its users Dealing with not-yet considered situations
may be ambiguous and inconsistent not absolute (some take priority) idealized rather than implementable not allocated to product processes are implementations of goals
Pre-requirements traceability
Pre-reqts.
Reqts.
1.1 The system shall blah, blah... 1.2 If the co-worker is blah, blah, the system shall inform the user ... 1.2.1...
Requirements criticism (challenging documented requirements) is about asking the right questions at the right times
raise questions
Annotated reqts.
Reqts. documentation
Refined reqts.
refine reqts.
...etc
Requirements Validation
_
Realism:
Requirements can be implemented and delivered
Traceability:
Each system function can be traced to a corresponding set of functional requirements
Objectives to accelerate process or minimize delay Specify in terms of average duration or wait time
but convenience (the real objective) often depends on eradicating excessive wait times but often not technically feasible to guarantee
So usually by putting ceiling on 95/99% cases Absolute deadlines are functional reqts. Hard real-time reqts. are substitutes for a response being required before an envt. event
Specification
performance
Ability to do a task without help within X minutes of using system for 1st time Average performance time for error-free task
If there are feasible meeting times, the system should in 95% cases schedule a meeting within 5 seconds of meeting constraints having been entered Usability A person should be able to fill in the scheduling constraints for an N-person meeting in fewer than 5*N keystrokes/mouse-clicks
Summary
_ _
Requirements Elicitation:
Greenfield Engineering, Reengineering, Interface Engineering
Scenarios:
Great way to establish communication with client As-Is Scenarios, Visionary scenarios, Evaluation scenarios Training scenarios Use cases: Abstraction of scenarios
_ _ _