Object Oriented Analysis and Design 1
Chapter 3 Understanding Requirements Requirements Vision Use-Case Modeling Software Requirements Specification Requirements Management Case Study and Project
Object Oriented Analysis and Design 2
Requirements
Object Oriented Analysis and Design 3
3.1 RequirementsWhat is RequirementsTypes of RequirementsRequirements Documents
Object Oriented Analysis and Design 4
What is requirement? Requirements are capabilities and conditions to
which the system (and more broadly, the project) must conform. [JBR99].
The purpose of Requirements is: To provide system developers with a better understanding
of the system requirements. To define the boundaries of (delimit) the system. To provide a basis for planning the technical contents of
iterations. To provide a basis for estimating cost and time to develop
the system. To define a user-interface for the system, focusing on the
needs and goals of the users.
Object Oriented Analysis and Design 5
Requirements Factors on challenged software projects
37% of factors related to problems with requirements,
Object Oriented Analysis and Design 6
Requirements Management Requirements management is a systematic
approach to eliciting, organizing, and documenting the requirements of
the system establishing and maintaining agreement between the
customer and the project team on the changing requirements of the system.
Keys to effective requirements management include maintaining a clear statement of the requirements, along
with applicable attributes for each requirement type traceability to other requirements and other project
artifacts.
Object Oriented Analysis and Design 7
Types of Requirements – FURPS+
Functional features, capabilities, security.
Usability human factors, help, documentation.
Reliability frequency of failure, recoverability, predictability.
Performance response times, throughput, accuracy, availability, resource
usage. Supportability
adaptability, maintainability, internationalization, configurability.
Object Oriented Analysis and Design 8
Types of Requirements – FURPS+ The "+" in FURPS+ indicates ancillary and sub-
factors, such as: Implementation
• resource limitations, languages and tools, hardware, ...
Interface
• constraints imposed by interfacing with external systems.
Operations
• system management in its operational setting. Packaging Legal
• licensing and so forth.
Object Oriented Analysis and Design 9
Types of Requirements – RUP Requirements are categorized as functional
(behavioral) or non-functional (everything else); Functional Requirements
Functional requirements are explored and recorded in
• the Use-Case Model • the system features list of the Vision artifact.
Non-functional Requirements Other requirements can be recorded in the use cases they
relate to, or in the Supplementary Specifications artifact.
Object Oriented Analysis and Design 10
Requirement Documents Vision
The Vision artifact summarizes high-level requirements that are elaborated in these other documents.
The Vision is a general vision of the core project's requirements, and provides the contractual basis for the more detailed technical requirements.
Include:
• Problem Statement• User or Stakeholder Descriptions• Product Overview • Features • Constraints
Object Oriented Analysis and Design 11
Requirement Documents SRS (Software Requirements Specification)
Functional requirements • Use case Model
Non-functional requirements• Supplementary Specification
Glossary • records and clarifies terms used in the requirements.
• also encompasses the concept of the data dictionary, which records requirements related to data, such as validation rules, acceptable values, and so forth
User-Interface Prototype
Prototypes are a mechanism to clarify what is wanted or possible.
Object Oriented Analysis and Design 12
Requirement Artifacts in UP
Object Oriented Analysis and Design 13
Vision
Object Oriented Analysis and Design 14
3.2 Vision Introduction Template Example How to develop Vision
Object Oriented Analysis and Design 15
Vision - Introduction The Vision document provides
a complete vision for the software system under development and supports the contract between the funding authority and the development organization.
The vision document is written from the customers' perspective, focusing on the essential features of the system and acceptable levels of
quality.
The Vision should include a description of what features will be included as well as those considered but
not included. It should also specify operational capacities (volumes, response times,
accuracies), user profiles (who will be using the system), and inter-operational interfaces with entities outside the system boundary, where applicable.
The Vision document provides the contractual basis for the requirements visible to the stakeholders.
Object Oriented Analysis and Design 16
Vision - Introduction The Vision document
is created early in the inception phase, and it is used as a basis for the Business Case and the
first draft of the Risk List The Vision document
serves as input to use-case modeling, and is updated and maintained as a separate artifact
throughout the project.
Object Oriented Analysis and Design 17
Vision - Introduction Purpose of Vision
Gain agreement on what problems need to be solved.
Identify stakeholders to the system. Define the boundaries of the system. Describe primary features of the system.
Object Oriented Analysis and Design 18
Vision - Template for small project 1. Introduction 2. Positioning
2.1 Problem Statement 2.2 Product Position Statement
3. Stakeholder and User Descriptions 3.1 Stakeholder Summary 3.2 User Summary 3.3 Key High-Level Goals and Problems of the
Stakeholders 3.4 User-Level Goals 3.5 User environment
Object Oriented Analysis and Design 19
Vision - Template for small project 4. Product Overview
4.1 Product Perspective 4.2 Assumptions and Dependencies
5. Product Features 5.1 <aFeature> 5.2 <anotherFeature>
6. Other Requirements and Constraints
Object Oriented Analysis and Design 20
Vision - Commentary to Template Problem Statement
Provide a statement summarizing the problem being solved by this project.
The following format may be used:The problem of [describe the problem]
affects [the stakeholders affected by the problem]
the impact of which is [what is the impact of the problem?]
a successful solution would be
[list some key benefits of a successful solution]
Object Oriented Analysis and Design 21
Vision - Commentary to Template Product Position Statement
Provide an overall statement summarizing, at the highest level, the unique position the product intends to fill in the marketplace.
The following format may be used:
For [target customer]
Who [statement of the need or opportunity]
The (product name) is a [product category]
That [statement of key benefit; that is, the compelling reason to buy]
Unlike [primary competitive alternative]
Our product [statement of primary differentiation]
Object Oriented Analysis and Design 22
Vision - Commentary to Template User Summary
Present a summary list of all identified users. The following format may be used:
Name Description Responsibilities Stakeholder
[Name the user type.]
[Briefly describe what they represent with respect to the system.]
[List the user’s key responsibilities with regard to the system being developed; for example:captures detailsproduces reportscoordinates workand so on]
[If the user is not directly represented, identify which stakeholder is responsible for representing the user’s interest.]
Object Oriented Analysis and Design 23
Vision - Commentary to Template Product Perspective
This subsection puts the product in perspective to other related products and the user’s environment.
If the product is independent and totally self-contained, state it here.
If the product is a component of a larger system, then this subsection needs to relate how these systems interact and needs to identify the relevant interfaces between the systems.
One easy way to display the major components of the larger system, interconnections, and external interfaces is with a block diagram.• System context diagram• High-level deployment diagram
Object Oriented Analysis and Design 24
Vision - Commentary to Template Product Features
Use cases are not necessarily the only way one needs to express functional requirements.
An alternative, a complementary way to express system functions is with features, or more specifically in this context, system features,
System features are high-level, terse statements summarizing system functions.
A system feature is "an externally observable service provided by the system which directly fulfills a stakeholder need" [Kruchten00].
Features are things a system can do. The point of system features in the Vision is
• to summarize the functionality, • not decompose it into a long list of fine-grained elements.
Keep feature descriptions at a general level. • Focus on capabilities needed and why (not how) they should be
implemented. • Avoid design.• It is common to organize a two-level hierarchy
Object Oriented Analysis and Design 25
Vision - Commentary to Template Other Requirements in the Vision
In the Vision, system features briefly summarize functional requirements expressed in detail in the use cases.
Likewise, the Vision can summarize other requirements (for example, reliability and usability) that are detailed in the Special Requirements sections of use cases, and in the Supplementary Specification (SS).
Object Oriented Analysis and Design 26
Vision - Example Course Registration System example
Vision 1 NextGen example
Object Oriented Analysis and Design 27
Vision - How to develop Vision Gain agreement on the problem being solved Identify stakeholders Define the system boundaries Identify constraints to be imposed on the system Formulate problem statement Define features of the system Evaluate your results
Object Oriented Analysis and Design 28
Vision - Checkpoints Have you fully explored what the "problem behind the
problem" is? Is the problem statement correctly formulated? Is the list of stakeholders complete and correct? Does everyone agree on the definition of the system
boundaries? If system boundaries have been expressed using actors, have
all actors been defined and correctly described? Have you sufficiently explored constraints to be put on the
system? Have you covered all kinds of constraints - for example
political, economic, and environmental. Have all key features of the system been identified and
defined? Will the features solve the problems that are identified? Are the features consistent with constraints that are identified?
Object Oriented Analysis and Design 29
3.3 Use-Case ModelingKey ConceptsUse-Case DiagramUse-Case SpecificationRelationship between Use-caseCheckpoints
Object Oriented Analysis and Design 30
Key Concepts
Object Oriented Analysis and Design 31
What Is System Behavior? System behavior is how a system acts and
reacts. It is the outwardly visible and testable activity of
a system System behavior is captured in use cases.
Use cases describe the system, its environment, and the relationship between the system and its environment.
Object Oriented Analysis and Design 32
What Is a Use-Case Model? A model that describes a
system’s functional requirements in terms of use cases
A model of the system’s intended functionality (use cases) and its environment (actors)
Student
View Report Card
Register for Courses
Login
Object Oriented Analysis and Design 33
What Are the Benefits of a Use-Case Model? Used to communicate with the end users and
domain experts Provides buy-in at an early stage of system
development Insures a mutual understanding of the requirements
Used to identify Who interacts with the system and what the system
should do The interfaces the system should have
Used to verify All requirements have been captured The development team understands the requirements
Object Oriented Analysis and Design 34
Major Concepts in Use-Case Modeling An actor represents anything
that interacts with the system. A use case is a sequence of
actions a system performs that yields an observable result of value to a particular actor.
Use Case
Actor
Object Oriented Analysis and Design 35
What Is an Actor? Actors are not part of the system. Actors represent roles a user of the
system can play. They can represent a human, a
machine, or another system. They can actively interchange
information with the system. They can be a giver of information. They can be a passive recipient of
information.
Actors are EXTERNAL.
Actor
Object Oriented Analysis and Design 36
Useful Questions in Finding Actors? Who will supply, use, or remove information? Who will use this functionality? Who is interested in a certain requirement? Where in the organization is the system
used? Who will support and maintain the system? What are the system’s external resources? What other systems will need to interact with
this one? Actor
Object Oriented Analysis and Design 37
Focus on the Roles An actor
represents a role that a human, hardware device, or another system can play.
?
Object Oriented Analysis and Design 38
A User May Have Different Roles
Charlie
Charlie asstudent
Charlie asprofessor
Professor
Student
Object Oriented Analysis and Design 39
Practice: Find the Actors In the Course Registration System
Requirements document, read the Problem Statement for the Course Registration case study.
As a group, identify the following Actors Description of the actor
Object Oriented Analysis and Design 40
Practice: Solution
Billing System
Registrar
ProfessorCourse Catalog
Student
A person who is registered to take courses at the University
The unabridged catalog of all courses offered by the University
The external system responsible for student billing
A person who is teaching classes at the University
The person who is responsible for the maintenance of the course registration system
Object Oriented Analysis and Design 41
What Is a Use Case?
Use Case
A sequence of actions a system performs that yields an observable result of value to a particular actor
Object Oriented Analysis and Design 42
Use Cases and Actors A use case models a dialog between actors
and the system. A use case is initiated by an actor to invoke a
certain functionality in the system.
Actor Use Case
Communicates Association
Object Oriented Analysis and Design 43
How to Find Use Cases Answer the following questions to
find use cases. For each actor you have identified,
what are the tasks the system would be involved in?
Does the actor need to be informed about certain occurrences in the system?
Will the actor need to inform the system about sudden, external changes?
What information must be modified or created in the system?
Object Oriented Analysis and Design 44
Naming the Use Case The name indicates what is
achieved by its interactions with the actor(s).
The name may be several words in length.
No two use cases should have the same name.
Register forCourses
Login
Maintain StudentInformation
Object Oriented Analysis and Design 45
Use-Case Diagram
Object Oriented Analysis and Design 46
Use case diagram Captures system functionality as seen by
users Built in early stages of development Purpose
Specify the context of a system Capture the requirements of a system Validate a system’s architecture Drive implementation and generate test cases
Developed by analysts and domain experts
Object Oriented Analysis and Design 47
How Would You Read This Diagram?
Course Catalog
View Report Card
Register for Courses
Submit Grades
Select Courses to Teach
Student
Professor
Billing System
Maintain Student Information
Maintain Professor Information
Login
Close Registration
Registrar
Object Oriented Analysis and Design 48
Use Case Diagram - Example
Development Manager
User Management
System ConfigurationAdministrator
Normal User
User Authentication
Query
Project Management
Project Manager
Object Oriented Analysis and Design 49
Use-Case Specification
Object Oriented Analysis and Design 50
Use-Case Specifications
Name Brief description Flows of Events Relationships Activity diagrams Use-Case diagrams Special requirements Pre-conditions Post-conditions Other diagrams
Use-Case Specifications
...
Use-Case Model
Actors
Use Cases
Object Oriented Analysis and Design 51
Use-Case Specifications - Flow of Events• A use case describes what a system (or a subsystem,
class, or interface) does but it does not specify how it does it.
• You can specify the behavior of a use case by describing a flow of event in text clearly enough for outsider to understand it easily.
• When you write this flow of events, you should include how and when the use case starts and ends, when the use case interacts with the actors and what objects are exchanged, and the basic flow and alternative flow of the behavior.
Object Oriented Analysis and Design 52
Use-Case Flow of EventsHas one normal, basic flow Several alternative flows
Regular variantsOdd casesExceptional flows handling error situations
Object Oriented Analysis and Design 53
Use-Case Specifications - Scenarios • A use case actually describes a set of sequences in
which each sequence in the set represents one possible flow through all those variations.
• A scenario is a specific sequence of actions that illustrates behavior.
• Scenarios are to use cases as instances are to classes, meaning that a scenario is basically one instance of a use case.
Object Oriented Analysis and Design 54
What Are Scenarios ? A scenario is an instance of a use case
Object Oriented Analysis and Design 55
What Is an Activity Diagram? An activity diagram in the use-case model can be
used to capture the activities in a use case. It is essentially a flow chart, showing flow of control
from activity to activity.
Flow of EventsThis use case starts when the Registrar requests that the system close registration.
1. The system checks to see if registration is in progress. If it is, then a message is displayed to the Registrar and the use case terminates. The Close Registration processing cannot be performed if registration is in progress.
2. For each course offering, the system checks if a professor has signed up to teach the course offering and at least three students have registered. If so, the system commits the course offering for each schedule that contains it.
Object Oriented Analysis and Design 56
Select Course
Check Schedule
Check Pre-requisites
Assign to course
Resolve conflicts
Update schedule
[ student added to the course ]
[ add course ]Delete Course
[ delete course ]
[ checks completed ] [ checks failed ]
Example: Activity DiagramActivity State
Synchronization Bar (Fork)
Guard ConditionSynchronization Bar (Join)
Decision
Concurrent threads
Transition
Object Oriented Analysis and Design 57
Use-Case Specifications - Example- User Management
1. Brief Description This use case is for adding and deleting users. When adding user, the privilege of the user will be assigned.2. Basic Flow B1. Start of use case Actor chooses User Management in main screen. B2. Prompt welcome screen System shall prompt actor the user management welcome screen. A1. Choose delete user B3. Choose add user Actor chooses Add User. B4. Prompt add user screen System shall prompt actor the add user screen which needs actor to input some information. These information include: User Name, User ID, User Password, User Role. B5. Submit Actor inputs the information and submits the screen. E1. User ID already exists E2. Not enough information B6. Prompt success System shall prompt actor success information.
Object Oriented Analysis and Design 58
Use-Case Specifications - Example3. Alternative FlowsA1. Choose Delete User From B2. Prompt welcome screenA1.1 Choose delete Actor chooses delete user.A1.2 Prompt delete user screen System shall prompt actor the delete user screen. In this screen, system shall lists all the user ID stored in system.A1.3 Choose user to delete Actor chooses the user ID to delete and submit this screen. E3. No user ID chosenA1.4 Prompt success System shall prompt actor success information.
4. Exception FlowsE1. User ID already exists From B5. Submit, The User ID actor inputs has already existed in the system. The system shall prompt actor to try another User ID。E2. Not enough information From B5. Submit, If actor does not input all the information, system can not add a user. The system shall prompt actor to input all the information.E3. No user ID chosen From A1.3 Choose user to delete, If actor does not choose a user to delete before submitting the screen, the system shall prompt actor an error that he/she should choose a user to delete.
Object Oriented Analysis and Design 59
Relationship between Use-Case
Object Oriented Analysis and Design 60
Relationship between Use-case (optional) include extend generalization
Object Oriented Analysis and Design 61
Relationship between Use-cases - include• <<include>> – An include relationship from use case A to use case B indicates that an instance of the use case A will also contain the behavior as specified by B. The behavior is included at the location which defined in A.
Offer a line of credit
Submit a load request
Perform credit check
<<include>> <<include>>
Object Oriented Analysis and Design 62
Relationship between Use-cases - include
<<include>>: Functional Decomposition Problem:A function in the original problem statement is too complex to be solvable
immediatelySolution:Describe the function as the aggregation of a set of simpler functions. The
associated use case is decomposed into smaller use cases
ManageIncident
CreateIncident
HandleIncident
CloseIncident
<<include>>
<<include>>
<<include>>
Object Oriented Analysis and Design 63
Relationship between Use-cases - include
<<include>>: Reuse of Existing Functionality
Problem:There are already existing functions. How can we reuse them?
Solution:The include association from a use case A to a use case B indicates that an instance of the use
case A performs all the behavior described in the use case B (“A delegates to B”)
Example: The use case “ViewMap” describes behavior that can be used by the use case “OpenIncident”
(“ViewMap” is factored out)
Note :The base case cannot exist alone. It is always called with the supplier use case
AllocateResources
OpenIncident
ViewMap
<<include>>
<<include>>
Base Usecase
Supplier Usecase
Object Oriented Analysis and Design 64
Relationship between Use-cases - extend
<<extend>>– An extend relationship from use case A to use case B indicates that an instance of use case B may be augmented (subject to specific conditions specified in the extension) by the behavior specified by A. The behavior is inserted at the location defined by the extension point in B which is referenced by the extend relationship.
Evaluate loan request
Request additional credit information
Refer loan request to loan committee
<<extend>>
<<extend>>
Object Oriented Analysis and Design 65
Relationship between Use-cases - extendProblem:The functionality in the original problem statement needs to be extended.Solution:An extend association from a use case A to a use case B indicates that use case B is
an extension of use case A.Example:The use case “ReportEmergency” is complete by itself , but can be extended by the
use case “getHelp” for a specific scenario in which the user requires help
Note :In an extend assocation, the base use case can be executed without the use case extension
getHelpFieldOfficer ReportEmergency
<<extend>>
Object Oriented Analysis and Design 66
Relationship between Use-cases - Generalization
Withdraw funds
Withdraw from savings
Withdraw from checking
Request credit card advance
With the introduction of UML 1.3, a new relationship between use cases was introduced - generalization
Generalization – A generalization from use case A to use case B indicates that A is a specialization of B.
Object Oriented Analysis and Design 67
Relationship between Use-cases - GeneralizationProblem:You have common behavior among use cases and want to factor this out.
Solution:The generalization association among use cases factors out common behavior. The
child use cases inherit the behavior and meaning of the parent use case and add or override some behavior.
Example:Consider the use case “ValidateUser”, responsible for verifying the identity of the
user. The customer might require two realizations: “CheckPassword” and “CheckFingerprint”
Parent usecaseChild usecase
CheckPasswordValidateUser
CheckFingerprint
Object Oriented Analysis and Design 68
Checkpoints
Object Oriented Analysis and Design 69
Checkpoints: Requirements: Use-Case Model Is the use-case model
understandable? By studying the use-case model, can
you form a clear idea of the system's functions and how they are related?
Have all functional requirements been met?
Does the use-case model contain any superfluous behavior?
Is the division of the model into use-case packages appropriate?
Object Oriented Analysis and Design 70
Checkpoints: Requirements: Actors Have all the actors been identified? Is each actor involved with at least one
use case? Is each actor really a role? Should any
be merged or split? Do two actors play the same role in
relation to a use case? Do the actors have intuitive and
descriptive names? Can both users and customers understand the names?
Object Oriented Analysis and Design 71
Checkpoints: Requirements: Use-Cases Is each use case involved with at least
one actor? Is each use case independent of the
others? Do any use cases have very similar
behaviors or flows of events? Do the use cases have unique,
intuitive, and explanatory names so that they cannot be mixed up at a later stage?
Do customers and users alike understand the names and descriptions of the use cases?
Object Oriented Analysis and Design 72
Checkpoints: Requirements: Use-Case Specifications Is it clear who wishes to perform a use-
case? Is the purpose of the use-case also
clear? Does the brief description give a true
picture of the use-case? Is it clear how and when the use-case's
flow of events starts and ends? Does the communication sequence
between actor and use-case conform to the user's expectations?
Are the actor interactions and exchanged information clear?
Are any use-cases overly complex?
Object Oriented Analysis and Design 73
Review: Requirements Overview What are the main artifacts of Requirements? What are the Requirements artifacts used for? What is a use-case model? What is an actor? What is a use case? List examples of use case
properties. What is the difference between a use-case and a
scenario? What is a supplementary specification and what
does it include? What is a glossary and what does it include?
Object Oriented Analysis and Design 74
3.4 Software Requirements Specification Identifying other requirements
Supplementary Specifications Glossary
Object Oriented Analysis and Design 75
Supplementary Specifications
Object Oriented Analysis and Design 76
SupplementarySpecification
Supplementary Specification
Functionality Usability Reliability Performance Supportability Design constraints
Object Oriented Analysis and Design 77
Supplementary Specification - Example Review the Supplementary Specification
provided in the Course Registration Requirements Document
Object Oriented Analysis and Design 78
Glossary
Object Oriented Analysis and Design 79
Glossary
Glossary
Course Registration System Glossary
1. Introduction
This document is used to define terminology specific to the problem domain, explaining terms, which may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information.
2. Definitions
The glossary contains the working definitions for the key concepts in the Course Registration System.
2.1 Course: A class offered by the university.
2.2 Course Offering: A specific delivery of the course for a specific semester – you could run the same course in parallel sessions in the semester. Includes the days of the week and times it is offered.
2.3 Course Catalog: The unabridged catalog of all courses offered by the university.
Object Oriented Analysis and Design 80
Glossary - Example Review through the Glossary provided in the
Course Registration Requirements Document
Object Oriented Analysis and Design 81
3.5 Requirements ManagementMaking sure you
Solve the right problemBuild the right system
By taking a systematic approach toeliciting organizing documenting and managing
the changing requirements of a software application.
Object Oriented Analysis and Design 82
Aspects of Requirements Management Analyze the Problem Understand User Needs Define the System Manage Scope Refine the System Definition Build the Right System
Object Oriented Analysis and Design 83
Problem
Solution Space
Problem Space
Needs
Features
Use Cases and SoftwareRequirements
Test ProceduresDesign User
Docs
The The Product Product To Be To Be BuiltBuilt
Traceability
Map of the Territory
Object Oriented Analysis and Design 84
3.6 Case Study and Project Inception Phase Case Study - CRS Project - Inception Phase
Object Oriented Analysis and Design 85
Inception Phase
Object Oriented Analysis and Design 86
Inception Phase Inception Phase :
Define the scope of the project and develop business case
The primary objectives of the inception phase include: Establishing the project's software scope and boundary
conditions, including an operational vision, acceptance criteria and what is intended to be in the product and what is not.
Discriminating the critical use cases of the system, the primary scenarios of operation that will drive the major design trade-offs.
Exhibiting, and maybe demonstrating, at least one candidate architecture against some of the primary scenarios
Estimating the overall cost and schedule for the entire project.
Estimating potential risks. Preparing the supporting environment for the project.
Object Oriented Analysis and Design 87
What Artifacts May Start in Inception?Artifact Comment
Vision and Business Case Describes the high-level goals and constraints, the business case, and provides an executive summary.
Use-Case Model Describes the functional requirements, and related non-functional requirements.
Supplementary Specification
Describes other requirements.
Glossary Key domain terminology.
Risk List & Risk Management Plan
Describes the business, technical, resource, schedule risks, and ideas for their mitigation or response.
Prototypes and proof-of-concepts
To clarify the vision, and validate technical ideas.
Iteration Plan Describes what to do in the first elaboration iteration.
Phase Plan & Software Development Plan
Low-precision guess for elaboration phase duration and effort.Tools, people, education, and other resources.
Development Case A description of the customized UP steps and artifacts for this project. In the UP, one always customizes it for the project.
Object Oriented Analysis and Design 88
Inception Phase - a suggested sequence 1. Write a brief first draft of the Vision. 2. Identify user goals and the supporting us
e cases. 3. Write some use cases and start the Suppl
ementary Specification. 4. Refine the Vision, summarizing informati
on from these.
Object Oriented Analysis and Design 89
Checkpoint: What Happened in Inception? Inception is a short step
to determine basic feasibility, risk, and scope.
Some likely activities and artifacts in inception include: a short requirements workshop most actors, goals, and use cases named most use cases written in brief format; 10-20% of the use cases are written in fully
dressed detail to improve understanding of the scope and complexity. most influential and risky quality requirements identified version one of the Vision and Supplementary Specification written risk list technical proof-of-concept prototypes and other investigations to explore the
technical feasibility of special requirements user interface-oriented prototypes to clarify the vision of functional requirements recommendations on what components to buy/build/reuse, to be refined in
elaboration high-level candidate architecture and components proposed plan for the first iteration candidate tools list
Object Oriented Analysis and Design 90
Sample requirements effort across the early iterations
Object Oriented Analysis and Design 91
Case Study (Covered in GCIS501)
Object Oriented Analysis and Design 92
Case Study - Course Registration System Vision SRS - Use Case Model SRS - Supplementary Specification SRS - Glossary
Object Oriented Analysis and Design 93
Project – Inception Phase
Object Oriented Analysis and Design 94
Project - Requirements Work as a team (max 3 person) Select topic Write the following Requirements artifacts:
Vision SRS
• Use-case model(Use-case diagram, Use-case specification, Activity Diagram)
• Supplementary specification • Glossary• User Interface (optional)
Top Related