Business Requirements

1
Business Requirements

• Dr. V. Sridhar
• Associate Professor
• IT Systems Group
• Indian Institute of Management
• Lucknow

2
How are good systems built?

• Uses a defined process with clear phases, each of
  which has an end-product
• Is concerned with meeting a clear set of
  requirements, carefully defined as early as
  possible
• Incorporates forms of verification and
  validation, such as testing which are just as
  essential as building the product itself
• Uses a store of relevant knowledge, architectures
  and components
• Makes sensible use of tools

3
System Development Life Cycle
4
The Context
                                                
                                                  
                                            click
5
Business Modeling

• To understand the structure and the dynamics of
  the organization in which a system is to be
  deployed (the target organization).
• To understand current problems in the target
  organization and identify improvement
  potentials. 
• To ensure that customers, end users, and
  developers have a common understanding of the
  target organization.
• To derive the system requirements needed to
  support the target organization.
• To achieve these goals, the business modeling
  discipline describes how to develop a vision of
  the new target organization, and based on this
  vision define the processes, roles, and
  responsibilities of that organization in a
  business use-case model.
• Problem Description of Course Registration System

6
Scope of Business Modeling

• Domain Modeling
• building applications with the primary purpose of
  managing and presenting information, such as an
  order management system or a banking system
• One Business Many Systems
• building a large system, or a family of
  applications, you may have one business-modeling
  effort that will serve as input to several
  software-engineering projects
• Generic Business Model
• building an application that will be used by
  several organizationsfor example, a sales
  support application or a billing application
• New Business
• start a completely new line of business (business
  creation), and will build information systems to
  support it
• Revamp
• completely revamp their way of doing business
  (business reengineering)
• Vision of Course Registration System

7
Purpose of Requirements

• To establish and maintain agreement with the
  customers and other stakeholders on what the
  system should do
• To give system developers a better understanding
  of the requirements of the system
• To delimit the system
• To provide a basis for planning the technical
  contents of the iterations
• To provide a basis for estimating cost and time
  to develop the system
• To define a user interface of the system focusing
  on the needs and goals of the users

8
Artifacts Overview
9
What are Requirements

• A requirement is defined as "a condition or
  capability to which a system must conform".
• FURPS Model
• Functionality
• Usability
• Reliability
• Performance
• Supportability
• FURPS Model
• design constraints
• implementation requirements
• interface requirements
• physical requirements

10
Functional Requirements

• Functional requirements specify actions that a
  system must be able to perform, without taking
  physical constraints into consideration.
• These are often best described in a use-case
  model and in use cases.
• Functional requirements thus specify the input
  and output behavior of a system.

11
Use-Case Model

• A use-case model is a model of the system's
  intended functions and its surroundings, and
  serves as a contract between the customer and the
  developers.
• Use cases serve as a unifying thread throughout
  system development.
• The same use-case model is the result of the
  Requirements discipline, and is used as input to
  Analysis Design and Test disciplines.
• Use case specifications is the document where all
  of the use case properties are documented

12
Use Case Model
Use Cases
Actor
Use Case Specifications
13
Actor and Use case

• Actor represents anything that interacts with
  the system
• A use case us a sequence of actions a system
  performs that yields an observable result of
  value to a particular actor

14
Course Registration Use Case Model
15
Use of Use Cases

• Use cases are a very good way of capturing
  functional requirements on a system.
• But what about the non-functional requirements?
• Many non-functional requirements apply to an
  individual use case and are captured within the
  properties of that use case.
• captured within the flow of events of the use
  case, or as a special requirement of the use case
• Glossary defines a common terminology for all
  models and contains textual descriptions of the
  required system

16
Benefits of a Use Case Model

• Used to communicate with the end users and domain
  experts
• 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

17
How Use Case Model Evolves

• Both the actors and the use cases are found by
  using the requirements of customers and potential
  users as vital information.
• As they are discovered, the use cases and the
  actors should be briefly described.
• When the actors and use cases have been found,
  the flow of events of each use case is described
  in detail. These descriptions show how the system
  interacts with the actors and what the system
  does in each individual case.
• Finally, the completed use-case model (including
  the descriptions of use cases) is reviewed, and
  the developers and customers use it to agree on
  what the system should do.

18
Use Case Properties

• Brief Description
• Flow of Events Basic flow, alternative flow
• Relationships
• Communicates-associations
• Includes and extends relationships
• Activity Diagram
• Illustrate the structure of the flow of events
• Use-case diagram
• Special Requirements
• Non functional requirements that need to be taken
  care of in analysis and design
• Pre-conditions
• Defines a constraint on the system for when the
  use case may start
• Post-conditions
• Defines a constraint on the system for after the
  use case has terminated
• Other Diagrams
• Use-case Register for courses

19
Use-case Flow of Events

• Contains the most important information derived
  from use-case modeling work
• Should describe the use cases flow clearly
  enough for an outsider to easily understand it
• Should present what the system does, not how the
  system is designed to perform the required
  behaviour
• Has one normal, basic flow
• Several alternative flows
• Regular variants
• Odd cases
• Exceptional flows handling error situations
• Use-case Register for courses
• Use-case Submit Grades

20
Contents in the Flow

• Details the flow of events
• Describe how the case starts and ends
• Describe the flow of events, not only the
  functionality
• Describes the events that belong to the use case
  and not what happens in other use cases or
  outside the system
• Describes the data exchanged between the actor
  and the use case
• Avoid vague terminology such as for example,
  etc

21
Scenerios

• A scenario is an instance of a use case
• Scenerios make excellent test cases
• The scenario may involve the basic flow and, any
  number of alternative flows in any number of
  combinations
• How many scenarios are needed?

22
Relationships between Use-cases

• Document relationship between two use-cases
• Two types of associations
• Stereotype ltltincludegtgt
• Stereotype ltltextendgtgt
• Source use case includes the target use case

Extend Loan
ltltincludegtgt
Check for Reservation
Borrow Copy of Book
ltltincludegtgt
Book Borrower
23
Use case for reuse ltltincludegtgt

• If you can factor out common behaviour from two
  or more use cases
• We can implement part of a use case by using a
  component

24
Separating variant behaviour ltltextendgtgt

• If a use case incorporates two or more
  significantly different scenarios
• Show variant cases using stereotype ltltextendgtgt
• From the less central case to the central case
• Exceptional case to the normal case

Refuse Loan
ltltextendgtgt Too many books On loan
Borrow Copy of Book -----------------------------
--- Extension points Status validation after
confirming identity
Book Borrower
25
Generalisation between Actors

• Two actors or use cases can be related by
  generalisation
• Every JournalBorrower is a BookBorrower
• From specialised actor/use case to general
  actor/use case

26
Generalizations
Reserve Book
Book Borrower
Reserve Book By Telephone
Journal Borrower
27
Activity Diagrams

• An activity diagram in the use-case model can be
  used to capture the activities in a use case
• Essentially a flow chart, showing flow of control
  from activity to activity
• The Consists of sequence of activities, that,
  together, produce something for the actor
• Workflow consists of a basic flow and one or more
  alternative flows
• The structure of the workflow can be described
  graphically with the help of an activity diagram

28
Activity DiagramRegister for Courses
Activity State
Synchronisation bars
Transition
29
Elements of the Activity Diagram

• Activity States
• Performance of an activity or step within the
  workflow
• Transitions
• What activity state follows after another
• Decisions
• Evaluate conditions defined by guard conditions
• Guard condition determine which of the
  alternative transitions will be made
• Synchronisation bars
• To show synchronization between parallel
  sub-flows
• Once all the activities which have transitions
  leading to the bar are complete, the bar can be
  passed

30
Glossary

• Defines the important terms used in the project
• Important to many developers to understand the
  use of terms that are specific to the project
• Facilitates communication between domain experts
  and developers
• System analyst is responsible for the integrity
  of the Glossary

31
Course Registration Glossary

• Introduction
• The glossary contains the working definitions
  for terms and classes in the Course Registration
  System. This glossary will be expanded throughout
  the life of the project. Any definitions not
  included in this document may be included in the
  Rational Rose Model.
• Definitions
• Course
• A class offered by the university.
• Course Catalog
• The unabridged catalog of all courses offered by
  the university.
• Faculty
• All the professors teaching at the university.

32
Non Functional Requirements

• Usability requirements
• human factors ( User-Centered Design), aesthetics
  , consistency in the user interface, online and
  context-sensitive help, wizards and agents , user
  documentation , training materials
• Reliability requirements
• frequency and severity of failure,
  recoverability, predictability, accuracy, mean
  time between failure (MTBF)
• Performance requirements
• Speed, efficiency, availability , accuracy ,
  throughput , response time, recovery time,
  resource usage
• Supportability requirements
• testability , extensibility , adaptability ,
  maintainability , compatibility , configurability
  , serviceability, installability , localizability
  (internationalization)
• Non-functional requirements can be captured in
  Supplementary Specifications
• A complete definition of the software
  requirements, use cases, and Supplementary
  Specifications
• Software Requirements Specification (SRS) for a
  particular "feature" or other subsystem grouping.

33
The Requirements

• Implementation Requirement
• required standards, implementation languages,
  policies for database integrity, resource limits,
  operation environments
• Interface Requirement
• an external item with which a system must
  interact, constraints on formats, timings, or
  other factors used by such an interaction
• Physical Requirement
• Material, shape, size, weight
• Supplementary Specifications

34
Checkpoints Use case Model

• Sample of the kinds of things to look for when
  reviewing the use-case model
• Explicit detailed checklists should be
  established for the project to support the review
  of use-case model
• Is the use-case model understandable?
• By studying the use-case model, can you form a
  clear idea of the systems functions and how they
  are related?
• Have all the functional requirements been met?
• Does the use-case model contain any superfluous
  behaviour?

35
Checkpoints 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?

36
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 behaviours or
  flow 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?

37
Checkpoints 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 cases flow of
  events starts and ends?
• Does the communication sequence between actor and
  use-case conform to the users expectations?
• Are the actor interactions and exchanged
  information clear?
• Are any use cases overly complex?

38
Checkpoints Glossary

• Does each term have a clear and concise
  definition?
• Is each glossary term included somewhere in the
  use case descriptions?
• Are terms used consistently in the brief
  descriptions of actors and use cases?

39
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?