Domain Analysis

aft
• Domain analysis: process by which a software engineer
learns background information.
• Domain: general field of business or technology in which the
customers expect to be using the software.
• Examples - Airline reservation, medical diagnosis, financial
analysis, manufacturing of paint, scheduling meeting, etc.
• Essence of domain analysis: to understand the problem and
make good decisions during requirements analysis and other
Dr
stages of the software engineering process.
• Sources of information for domain analysis: the domain
experts, any book about the domain, any existing software
and its documentation, etc.
• Techniques used for Domain Analysis: interviewing,
brainstorming and use case analysis.
 Importance of Domain Analysis

aft
1. Faster development: effective communication with the
stakeholders, rapid establishment of requirements, help
developer to focus on the most important issues.
2. Better System: developed solutions will more effectively
solve the customer’s problem, fewer mistakes, developer will
know about which procedures and standards to follow, better
Dr
abstractions and hence improved designs.
3. Anticipation of extensions: better insights into emerging
trends, notice opportunities for future development, build a
more adaptable system.
 Domain Analysis Document

aft
Domain analysis document should be divided into following
sections:
1. Introduction: domain name, and motivation for performing
the analysis.
2. Glossary: meanings of all terms used in the domain that are
either not part of everyday language or else have special
meanings.
3. General knowledge about the domain
Dr
• Important facts or rules that are widely known by the domain
experts.
• Includes scientific principles, business processes, analysis
techniques, and how any technology works.
4. Customers and users: “who will or might buy the
software?”, and “In what industrial sectors they operate?”
 Domain Analysis Document (cont.)

aft
5. The environment
• Describe the equipment and systems used.
• The new system or extensions will have to work in the context
of this environment.
6. Tasks and procedures currently performed: list of what
the various people do as they go about their work.
7. Competing software: what software is available to assist the
Dr
users and customers, including software that is already in use,
and software on the market.
8. Similarities across domains and organizations:
determining what distinguishes this domain and the
customer’s organization from others, as well as what they
have in common.
 The starting point for software projects

aft
Dr Figure: Starting points for software projects
• Requirement Analysis
• Defining the problem to be solved and
• “What software will be created to solve it?”
 Defining the problem and the scope

aft
• A problem can be expressed as a difficulty the users or
customers are facing, or as an opportunity that will result in
some benefit such as improved productivity or sales.
• The solution to the problem: development of a software.
• A good problem statement is short and succinct – one or two
sentences is best.
• ExampleDr
• Domain: Student Registration System
• Problem Statement: “The system will allow students to
register for courses, and change their registration, as simply
and rapidly as possible. It will help students achieve their
personal goals of obtaining their degree in the shortest
reasonable time while taking courses that they find most
interesting and fulfilling.”
Defining the problem and the scope (cont.)
• If the problem is broad, or contains a long list of

aft
sub-problems, then the system will have a broad scope, and
hence be more complex.
• Objective: narrow down the scope by defining a more
precise problem.
• In the previous example, if we had stated: “the system will
automate all the functions of the registrar’s office”.
• Open the possibility of including features such as fee payment,
printing class lists and allocating rooms to courses.
Dr
Figure: Narrowing the project’s scope
Defining the problem and the scope (cont.)

aft
• All the requirements gathering and analysis techniques can
help in defining the problem and hence the system’s scope.
• Interviewing: can give the stakeholder’s personal perspectives.
• Brainstorming: can generate lists of ideas from which you can
extract a suitable problem or problems.
• Use case analysis: can give a list of the possible things the
Dr
system could do; and
• Prototyping: can give everybody (all stakeholders) a better
perspective about what might be possible.
 What is a requirement?

aft
A requirement is a statement describing either
• an aspect of “what the proposed system must do”, or
• a constraint on the system’s development.
In either case, it must contribute in some way towards adequately
Dr
solving the customer’s problem; the set of requirements as a whole
represents a negotiated agreement among all stakeholders.
 Types of requirements

aft
Requirements can be divided into four major types: functional,
quality, platform and process.
1. Functional Requirements
• describe “what the system should do”.
• describe the services provided for the users and for other
systems.
• The functional requirements can be further categorized as
follows:
• What inputs the system should accept, and under what
Dr conditions.
• What outputs the system should produce, and under what
conditions.
• What data the system should store that other systems might
use.
• What computations the system should perform.
• The timing and synchronization of the above (only for hard
real-time systems).
 Types of requirements (cont.)

aft
2. Quality Requirements
• Ensure the system possesses quality attributes such as
usability, efficiency, reliability, maintainability and reusability.
• These requirements constrain the design to meet specified
levels of quality and must be verifiable.
2.1 Response Time
• For systems that process a lot of data or use a network
Dr extensively, the system must give results or feedback to the
user in a certain minimum time.
• For hard real-time systems, response time requirements should
be considered to be functional - the system would not work
unless they are adhered to.
 Types of requirements (cont.)

aft
2.2 Throughput
• Computations or transactions per minute.
• Applicable for number-crunching programs that may take
hours, or for servers that continually respond to client
requests.
2.3 Resource Usage
• For systems that use significant amounts of resources such as
memory and network bandwidth, developer should specify the
Dr maximum amount of these resources that the system will
consume.
2.4 Reliability
• Measured as the average amount of time between failures or
the probability of a failure in a given period.
2.5 Availability
• Measures the amount of time that a server is running and
available to respond to users.
 Types of requirements (cont.)

aft
2.6 Recovery from failure
• Constrain the allowed impact of a failure.
• If the hardware or software crashes, or the power fails, then
the system will be able to recover within a certain amount of
time, and with a certain minimal loss of data.
2.7 Allowances for maintainability and enhancement
• This constrains design and improves quality without adding
explicit new functional requirements.
• In order to ensure that the system can be adapted in the
Dr future, you should describe changes that are anticipated for
subsequent releases.
2.8 Allowances for reusability
• It is desirable in many cases to specify that a certain
percentage of the system, e.g. 40%, measured in terms of lines
of code, must be designed generically so that it can be reused.
 Types of requirements (cont.)

aft
3. Platform Requirement: constrains the environment and
technology of the system.
3.1 Computing platform
• What hardware and operating system the software must be
able to work on.
• Platform constraint says it is not guaranteed to run a software
if inadequate or incorrect resources are available.
• Specify the least powerful platforms and declare that it must
Dr work on anything more recent or more powerful.
• Different from the resource usage constraint on memory.
3.2 Technology to be used
• Constraints on the technology to be used for software
development.
• Common Examples: programming language or database
system.
• Reduces the need to train people in different technologies.
 Types of requirements (cont.)

aft
4. Process requirements: constrains the project plan and
development methods.
4.1 Development process (methodology) to be used
• In order to ensure quality, some requirements documents
specify that certain processes be followed; for example,
particular approaches to testing.
4.2 Cost and delivery date
Dr
• Important constraints.
• Usually, the project cost and delivery date are usually not
placed in the requirements document, but are found in the
contract for the system or are left to a separate
project plan document.
 Use cases: describing how the user will
use the system

aft
Use case analysis
• Systematic approach to working out what users should be able
to do with the software you are developing.
• Key activity in requirements analysis.
• Determine the types of users or other systems (also called as
actors) that will use the facilities of this system.
Dr
• An actor is a role that a user or some other system plays when
interacting with your system; each actor will need to interact
with the system in different ways.
• Determine the tasks that each actor will need to do with the
system.
• Each task is called a use case because it represents one
particular way the system will be used.
 Use cases: describing how the user will
use the system (cont.)

aft
Use Case
• Definition: A use case is a typical sequence of actions that
an actor performs in order to complete a given task.
• Developer must list the use cases that only actors will need to
do when they are using the system to solve the customer’s
Dr
problem.
• One can also list a set of use cases to help define the system’s
scope.
 Use cases: describing how the user will
use the system (cont.)

aft
How to describe a single use case
• Name: give a short, descriptive name to the use case.
• Actors: list the actor or actors who can perform this use case.
• Goals: explain what the actor or actors are trying to achieve.
• Preconditions: describe the state of the system before the
use case occurs by listing any conditions that must be true
Dr
before an actor can initiate this use case.
• Summary: summarize what occurs as the actor or actors
perform the use case.
• Related use cases: list use cases that may be generalizations,
specializations, extensions or inclusions of this one.
 Use cases: describing how the user will
use the system (cont.)

aft
• Steps: describe each step of the use case using a two-column
format, with the left column showing the actions taken by the
actor, and the right column showing the system’s responses.
• Postconditions: what state is the system in following the
Dr
completion of this use case.
 Use cases: describing how the user will
use the system (cont.)

aft
Use case diagrams
• Use case diagrams are UML’s notation for showing the
relationships among a set of use cases and actors.
• Use case diagrams help a software engineer to convey a
high-level picture of the functionality of a system.
Dr
Figure: A simple use case diagram showing three actors and five use
cases
 Use cases: describing how the user will
use the system (cont.)

aft
Use case model
• A use case model consists of a set of use cases, and optional
descriptions or diagrams indicating how they are related.
• Use case analysis is an intuitive way to understand and
Dr
organize what the system should do, since it is based on
user tasks and expresses the tasks in natural language.
 Use cases: describing how the user will
use the system (cont.)

aft
The benefits of basing software development on use cases
Use cases:
• Can help to define the scope of the system – that is, what the
system must do and does not have to do.
• Are often used to plan the development process
Dr
• The number of identified use cases is a good indicator of a
project’s size.
• Development progress can be measured in terms of the
percentage of use cases that have been completed.
 Use cases: describing how the user will
use the system (cont.)

aft
Use cases:
• Are used to both develop and validate the requirements.
• If some piece of proposed functionality does not support any
use case, then it can be eliminated.
• Users and customers can also understand requirements better
if they are expressed in terms of use cases.
Dr
• The use cases therefore can serve as part of the contract
between the customers and the developer.
• Can form the basis for the definition of test cases.
• Can be used to structure user manuals.
 Use cases: describing how the user will
use the system (cont.)

aft
Scenarios
• A scenario is an instance of a use case that expresses a
specific occurrence of the use case with a specific actor
operating at a specific time and using specific data.
Dr
• It can help to clarify the associated use case.
• It is also often simply called a use case instance.
 Techniques for gathering requirements

aft
Gathering requirements is an iterative process that must be
combined with a process of analyzing the requirements to
systematically organize and prioritize them.
1. Observation
• The process of observing the potential users at work and
writing down everything they do.
• One can also ask users to talk as they work, explaining what
they are doing.
Dr
• Videotaping of the session so that one can analyze it in more
detail later.
• Observation, and analyzing the resulting information, can
consume a large amount of time.
• Therefore, it is done only for the development of large systems
with which potential users will be performing complex tasks.
Techniques for gathering requirements (cont.)

aft
2. Interviewing
• A well-conducted series of interviews can elicit much more
information than poorly planned ad-hoc interviews.
• Software engineers are rarely trained in conducting interviews.
• Guidelines
• Plan to have as many members of the software engineering
team interview as many stakeholders as possible.
• Consider going beyond stakeholders, talking to users of
Dr competing products, marketing personnel, and people involved
with other systems that may interact in any way with the
proposed system.
• Spread out the interviews over time, and allow yourself several
hours for each interview, even if you do not expect to use that
much time
• Prepare an extensive list of questions.
Techniques for gathering requirements (cont.)

aft
3. Brainstorming
• Effective way to gather information from a group of people.
• Idea: the group sits around a table and discusses some topic
with the goal of generating ideas.
• Keys to success: arranging for the brainstorming session
to be led, or moderated, by somebody trained in the process

Dr
Figure: Structured brainstorming: passing ideas around the
table to stimulate new ideas
Techniques for gathering requirements (cont.)

aft
• Advantage of Brainstorming
• In a moderated group session, people are energized and tend
to spontaneously invent many good ideas, stimulated by what
others have said.
• Introverted or timid people can have their say effectively since
anonymity can be assured.
• A lot of thinking goes on in parallel: during the first phase,
Dr everybody is thinking of their own ideas and writing them
down concurrently.
• The session is more productive than if everybody had to
wait their turn to express their ideas.
Techniques for gathering requirements (cont.)

aft
4. Prototyping
• A prototype is a program that is rapidly implemented and
contains only a small part of the anticipated functionality of a
complete system.
• Purpose is to gather requirements by allowing software
engineers to obtain early feedback about their ideas.
• Intent is to test and validate existing ideas, as well as to
generate new ideas.
• Paper prototype
Dr
• The simplest kind of prototype of the user interface.
• Set of pictures of the system that are shown to customers and
users in sequence, to explain what would happen when the
system runs.
• Very powerful tool for eliciting ideas and feedback, and
requires very little effort to create.
• Ideal for parallel development.
Techniques for gathering requirements (cont.)
• ’mock-up’ of the system’s user interface

aft
• Most common type of prototype created using a rapid
prototyping language.
• Rapid prototyping languages allows you to create
code very quickly in order to display the important parts of a
user interface; however, they have various weaknesses that
limit their usefulness for creating the final version of complex
systems.
• Actual use of a rapid prototype
• It may not perform any computations, access any databases or
Dr interact with any other systems.
• Developer should modify a rapid prototype as many times as
necessary in response to feedback from users.
• Developer could not have put effort into designing its
architecture, therefore it will become hard to maintain, and
will contain many bugs.
• Difficult to turn it directly into the final system, therefore used
only as a requirements gathering tool.
 Types of requirements document

aft
• To perform good software engineering, it is always appropriate
to write down requirements.
• The level of detail of the requirements can, however, vary
significantly from project to project.
• Developer have to produce several requirements documents,
each describing a different part of the system or a different
level of detail.
Dr
• Requirements documents for large systems are normally
arranged in a hierarchy.
• There is a top-level document describing the overall system, its
subsystems and how the subsystems interact.
• There are separate documents describing each subsystem, and
sometimes each sub-subsystem.
Types of requirements document (cont.)

aft
Dr
Figure: Hierarchies of requirements documents
 Types of requirements document (cont.)

aft
Important factors to decide on what type of document
to produce:
1. The size of the system
• A large system will need more detailed requirements.
• The system will need to be divided into subsystems so that
different teams can work on each part.
2. The need to interface to other systems
• Even a small system will need to have well-described
Dr
requirements if other systems or subsystems are going to use
its services or communicate with it.
3. The target audience
• The requirements must be written at a high-enough level so
that the potential users can read them.
 Types of requirements document (cont.)

aft
4. The contractual arrangements for development
• If you are arranging a contract by which a third party will
develop software for you, then you will have to specify the
requirements with considerable precision.
• Similarly, if you are developing requirements under contract,
for a military client, for example, then you will have to follow
specific rules regarding the format and detail to be provided.
5. The stage in requirements gathering
Dr
• An outline describing a system or subsystem in a few
paragraphs or pages.
• Once all the stakeholders agree with a short, informal
statement of requirements, successive levels of detail can be
added.
• Follow the process of repeatedly prototyping as an integral part
of the requirements gathering process.
 Types of requirements document (cont.)

aft
6. The level of experience with the domain and technology

• Well-known domain and using well-known technology

• Produce a complete requirements document before starting to
design the system.
• Developing innovative software
• Develop prototypes based on rough requirements to check out
the validity of your ideas or the reliability of the technology.
Dr
7. The cost incurred if the requirements are faulty
• Any system that, if it fails, could jeopardize safety or the
environment, must be precisely specified.
• Furthermore, those specifications should be subjected to
rigorous analysis and review.
 Reviewing requirements

aft
• Early prototypes or drafts of requirements should be reviewed
by the author and stakeholders, and there may need to be
several cycles of improvements and repeated review.
• Each individual requirement should be carefully reviewed.
• In order to be acceptable, a requirement should:
• have benefits that outweigh the costs of development
• be important for the solution of the current problem
• be expressed using a clear and consistent notation
•
•
•
•
Dr
be unambiguous
be logically consistent
lead to a system of sufficient quality
be realistic with available resources
• be verifiable
• be uniquely identifiable
• not over-constrain the design of the system
 Reviewing requirements (cont.)

aft
Guidelines for requirements document as a whole
• The document should be sufficiently complete
• The document should be well organized
• Reasoning should be clear
Dr
• The document should be agreed to by all the stakeholders
IEEE format of Software Requirement Specification
Document

aft
1. Introduction
1.1 Purpose of requirement document
1.2 Scope of the product
1.3 References
1.4 Abbreviations
1.5 Remainder part of SRS document
2. General Descriptions
2.1 Product perspective
2.2 Product functionality
Dr
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
3. Specific Descriptions
3.1 Functional requirements
3.2 Non-functional requirements
3.3 Domain requirements
4. Appendix
5. Index
 Managing changing requirements

aft
• By the time the system is delivered, the users and customers
needs will likely have evolved so that the requirements as
documented no longer completely solve the customers
problem.
• The following are some of the changes to anticipate:
• Business process changes
• Businesses regularly adjust the way they do things in order to
Dr better compete in the market or merely because they gain
experience and decide that an alternative approach is better.
• Changes to business processes can also be prompted by such
things as changes in laws, as well as growth or rearrangement
of the company.
 Managing changing requirements (cont.)

aft
• Technology changes
• A new release of the operating system, or some other system
with which your system interacts, may force you to reassess
the requirements.
• Better understanding of the problem
• Even though everybody might be confident about the
requirements when they are first approved, various
stakeholders may discover problems when looking at them
Dr again several months later.
• Requirements analysis should therefore never really stop.
• The development team should continue to interact with the
customers and users, asking them about their problems and
their ideas and showing them prototypes of the system.
• Changes to the requirements should be made whenever the
benefits of doing so outweigh the costs.
 Difficulties and risks in domain and
requirements analysis

aft
• Misunderstanding and lack of understanding of the domain or
the real problem.
• Requirements can change rapidly, resulting in requirements
’churn’.
Dr
• Attempting to do too much.
• It may be hard to reconcile conflicting sets of requirements.
• It is hard to state requirements precisely.