ISYS-1117

ISYS1117 Home page

What is a requirement?

"Confidence in nonsense is a requirement for the creative process." --Unknown

Table Of Contents
n a normal software engineering
scenario, a project goes through the
following steps:

Planning
Requirements Analysis
Requirements Specification
Systems Design
Software Implementation
Software Testing
Software Release and
Software Maintenance

1.0 - Requirements Analysis - Prelude

1.1 - What is a requirement
2.0 - Requirement scenarios
3.0 - Fact finding techniques
3.1 - Interviewing
3.2 - JAD
3.3 - JAD & Questionnaire
4.0 - Specification & SRS
4.1 - SRS
5.0 - Functional vs Non-functional
requirements
6.0 - Specification Review
7.0 - References & Acknowledgments

There is no definitive length or time-frame fixed or defined for these activities.

Depending upon the project length, its scope and project-deadlines-these activities take
their shape. It is equally possible that these activities might overlap. It is, however,
important to realise that some activities among above have more weighting than others.
Requirements Analysis is one such activity which is one of the most crucial.
Requirements Analysis is the process of gathering information about the current system
or the system under analysis. The system might or might not be computerised. In the
Requirements Analysis stage, one outlines the strengths and weaknesses of the system.
After understanding the requirements of the system, it can be decided whether a new
system is required or not. Under a broader picture, it can be divided into some smaller
steps:

Understanding the sysytem

Identifying improvements and

Developing the concept of the new system (if needed)

These three steps are highly cohesive and iterative. This is the 'real secret' behind a good
software requirement practice. Thus, a real analyst would always flip back and forth
between information gathering and analysis. Based on that, an analyst would suggest
implementations. Sometimes some other terms are associated with the above steps. In
particular the following three terms are really substantial.
Elicitation
In elicitation one should identify the users requirements.
Analysis
Here one should analyse and develop this information to create an unambiguous picture
of the system to be built.
Specification Stage
This involves the thorough documentation of the scenario through reports and models.
Another important term used it system. Now what is a system?
A system is a set or arrangements of elements that are organised to accomplish some predefined goal by processing information. Software, hardware, people, database,
documentation and procedures all constitute what is known as the components of a
system. It is important to understand that even if a system is a non-trivial system, its
needs must be specified.
For instance, one can state that a bridge must support at least 1,000 tons, must be 30
metres wide, etc. In that sense, the specification is a precise statement of the requirements
of that system. Thus we can say that a Requirements Specification is an agreement
between the end user and the system developer.
Before going ahead it is important to know that REQUIREMENTS can be broadly
classified into two categories:

Functional requirements are those that relate directly to the functioning of the
system.
Non-Functional requirements are those which cover aspects of the system such as
user-interface, performance, quality issues, interfaces to other systems, and
security.

We shall cover these later in more detail.

Checkpoint
1. What is the difference between Software Elictitation and Software Analysis?
2. One of the major components of the requirements analysis study is to outline a clear cut
picture of 'specifications'. As said earlier, Requirements Specification is an agreement
between the end user and the system developer. One should keep in mind the fact that
these specifications must be consistent.
Suppose you were asked to define the specifications of a software system that your
team is going to first conceptualise and then build. Suppose this software is nothing but a
word processor. Can you define two consistent software specifications for such a system.

ISYS1117 Home page

ISYS 1117 - Software Engineering
Analysis and Design
Online Tutorials

What is a requirement?
Copyright 2002 RMIT Computer
Science
All Rights Reserved

ISYS-1117
Requirements analysis - Prelude

Requirement scenarios

Table Of Contents

Before we go into detail of why

Requirements Analysis is required it is
important to first define what a
Requirement is.
Every system development process begins
with an initial list of user needs, identified
problems and/or directives. These are
nothing but the requirements of the system.
A Requirements Definition Document is a
list in simple language of these functions
and constraints.

1.0 - Requirements Analysis - Prelude

1.1 - What is a requirement
2.0 - Requirement scenarios
3.0 - Fact finding techniques
3.1 - Interviewing
3.2 - JAD
3.3 - JAD & Questionnaire
4.0 - Specification & SRS
4.1 - SRS
5.0 - Functional vs Non-functional
requirements
6.0 - Specification Review
7.0 - References & Acknowledgments

Furthermore, Requirements Analysis is the process of sitting down and thinking carefully
about what your system should be able to do. Consider an example from your day-to-day
scenario - Starting with looking at your personal requirements, this essential first step of
buying a PC lays the foundation for looking at the PC's requirements, and then of course,
determining the characteristics of the equipment that will fulfill these needs. Planning and
analysis activities are considered by many to be dry and uninteresting compared to getting
'hands on' and playing with the hardware. Or even better, actually buying something and
getting to take it home and plug it in! However, it is absolutely essential that this first step
is not skipped over. Let us look at some of the requirements analysis that you need to go
through before you actually buy a PC.

Do I actaully need to buy a PC?

Which one should i buy-the branded one or the assembled one?
Which ones are more popular?
Well, I have to do that requirements vs price tradeoff analysis as well.
Or should I buy a notebook instead of a desktop PC?
Will I get warranty?

Now these are some of the questions that might rock someone's mind. It is important to

see that such an analysis at the inception stage of a project is very important for its later
success. Be it a large or small project, one from your daily live - requirements analysis is
essential.

How we do go about the process of requirements analysis

and elicitation?
Over many decades, investigators have identified analysis problems and their causes, and
have developed a variety of modeling notations and corresponding set of heuristics to
overcome them. Each analysis method has a unique point of view. However, all the
analysis and elicitation methods are related to a set of the same operational principles.
These are:

The information domain of a problem must be represented and understood.

The functiosn of the system/software to be bulit must be understood.
The behaviour of the system also needs to be analysed.
The analysis process should move from essential information towards
implementation details.

By following these principles, analysts approach towards a system systematically. One of

the very famous analysts, Davis, suggested a requirements engneering approach that
states:

Understand the problem before you begin to create the analysis model.
Develop prototypes after you have outlined the basic requirements of the system.
Record the origin and reason of every requirement.
Use multiple views of requirements.
Prioritize requirements.
Work to eliminate ambiguity.

Thus we can see that, although there are different theories, they all follow the same path.

Requirements analysis - Prelude

ISYS 1117 - Software Engineering
Analysis and Design
Online Tutorials

Requirement scenarios
Copyright 2002 RMIT Computer
Science
All Rights Reserved

ISYS-1117
What is a requirement

Fact finding techniques

Table Of Contents

et us look at some practical

scenarios. This is an outline of the
requirements analysis done by a
HUMAN RESOURCE company.
Look at this diagram

1.0 - Requirements Analysis - Prelude

1.1 - What is a requirement
2.0 - Requirement scenarios
3.0 - Fact finding techniques
3.1 - Interviewing
3.2 - JAD
3.3 - JAD & Questionnaire
4.0 - Specification & SRS
4.1 - SRS
5.0 - Functional vs Non-functional
requirements
6.0 - Specification Review
7.0 - References & Acknowledgments

This image is a copyright of

http://www.manningaffordability.com/S&tweb/HEResource/Process/S2PD.htm
Let us now look at some classical mistakes that an organisation/people might make to
avoid a detailed Requirements Analysis:
I wont require this analysis stage because... You will require it because...

What managers in the developing

company think the website should
offer, is certainly interesting
The management objection: We have done a information, but these managers are
management survey/brainstorm and we know not the future users. What they want on
what we want.I'm a manager and I'm in the
the site is not (necessarily) what users
business for 20 years. I know what the user
want on the site. What managers know
needs.I'm a user, I know what I need.Who
about future users is what they need to
cares about the requirements analysis and
know for their job. Since their job is
eliciation stage......
not designing websites, they probably
don't have the kind of knowledge about
users that is needed to design
interactive systems.
The creator's objection: We have a team with
great ideas, creative concepts, powerful
technologies. Surely they can design a great
system. So who cares about the requirements
analysis and eliciation stage......

Creativity and technology provide

solutions. We still need to solve a real
problem with this solution or it will not
be used. Do you want to design a
product that the creators think is great
or a product that users think is great?

The budget objection: We don't have the

budget for user requirements analysis.

The cost of learning something about

users you didn't want to know at the
start of a web project, is small
compared to the cost of learning it after
launching the website.

User requirements analysis can be

scaled to the size of the project. It's
better to do a 5-day analysis than no
analysis at all. User requirements
analysis should be planned from the
beginning of a project. Time-to-market
The planning objection: It doesn't fit in our
is less important than being in the
planning. We want to launch our website in 2
market with a product that is used by
months.
users. First mover advantage is often
misunderstood. You don't create a first
mover advantage by launching a
website. It's the user who creates the
first mover advantage by using your
site. If s/he doesn't, no advantage.

If your system is so new that nothing is

related to it, there's a big chance that
nobody will understand nor use the
system. If users can't relate to your
product, you probably don't have a
The novelty objection: What we're developing
market. If you don't know the current
is something completely new. There's nobody
way of working, how will you know
to analyze. We don't care how people
whether the new way is more
currently work. We're going to provide a new
effective? Are you sure you will not
way of working with the system.
create new problems with the system?
On what are you going to base design
decisions for the new system if you
don't know the current way of
working?
User requirements analysis uses some
techiques derived from social science
research. However, it is not like
scientific research in its goals nor the
way it is conducted. User requirements
The academic objection: User requirements
analysis sounds like academic research. We're analysis is entirely focused on
not at the university. We're a company
designing effective interactive systems.
It does not pretend to answer research
developing a website.
questions beyond that goal. In addition,
timing and costs of the analysis are
reduced to meet development
demands.

Checkpoint
1. What are some typical mistakes an organization might commit while analysing
requirements?
2. A developing team member argues-"...Instead of analyzing user requirements, we will
make a prototype and test that with users." How will you counter-argue them?

What is a requirement
ISYS 1117 - Software Engineering
Analysis and Design
Online Tutorials

Fact finding techniques

Copyright 2002 RMIT Computer
Science
All Rights Reserved

ISYS-1117
Requirement scenarios

Interviewing

Where facts are few, experts are many. --Donald R. Gan

o implement the plan, the analyst

needs to gather the right
information.While gathering
information, an analyst should look at all the
possible clues and should try to gather as
much information as he/she can. There are
various fact finding techniques that an
analyst can adopt-some of them being:

Looking into documents

Interviewing
JAD
UML approach such as Use-cases
Questionnaires, Observations,
Sampling

Table Of Contents
1.0 - Requirements Analysis - Prelude
1.1 - What is a requirement
2.0 - Requirement scenarios
3.0 - Fact finding techniques
3.1 - Interviewing
3.2 - JAD
3.3 - JAD & Questionnaire
4.0 - Specification & SRS
4.1 - SRS
5.0 - Functional vs Non-functional
requirements
6.0 - Specification Review
7.0 - References & Acknowledgments

Fact Finding Techniques

Lets us now look at some of these.

Interviewing
"Any fact facing us is not as important as our attitude toward it,
for that determines our success or failure."
- Norman Vincent Peale
An Interview is one of the most important and basic techniques to gather information. Normally
they are conducted one-to-one , but sometimes group interviews might also be held. But before
interviewing it is important for the analyst to make sure they are interviewing the right people. In
order to know that, it is important to clearly outline all the key stakeholders of the intended

system. Thus some important steps would be:

Selecting interviewees
Desigining the Interview questions
Preparing for an Interview
Conducting the Interview
Follow-up

One should start with creating an interviewing schedule. This should list all the interviewees along
with the time and purpose of their Interview. It is very important to have a clear opinion on who is
going to be interviewed. This can be crucial to the success of the project. As an example,
MICROSOFT, before even launching any new product, undergoes a massive interviewing
session with a lot of target end-users. This gathers a lot of information, even before they have
embarked upon a project. This gives them a cutting edge over their competitors.
While Interviewing the right people, analyst can come up with more ideas and some facts that
have reamined latent even during the preliminary stages of requirements elicitation phase.
The next important step is how to design interview questions?
Normally the questions fit three categories:

Open-ended questions: questions that leave room for elaboration on the part of the
interviewee.
Closed-ended questions: questions which require a specific answer such as YES or NO.
Probes: are the ones that follow up or supplement the above questions, asking for more
detail.

Let us examine those in a bit of detail.

Open-ended questions are questions to which there is not one definite answer. Open-ended
questions may be a good way to break the ice with a survey, giving respondents an opportunity to
answer in their own words. Example: "Are there any other comments about the course you would
like to add?" The responses to open-ended questions can be very useful, often yielding quotable
material. The drawback to open-ended questions is that the responses are more difficult to
catalogue and interpret.
Closed-ended questions have a finite set of answers from which the respondent chooses. One of
the choices may be "Other." It is a good idea to allow respondents to write in an optional response
if they choose "Other." The benefit of closed-ended questions is that they are easy to standardize,
and data gathered from closed-ended questions lend themselves to statistical analysis. The down
side to closed-ended questions is that they are more difficult to write than open-ended questions.
This is because the evaluator must design choices to include all the possible answers a respondent
could give for each question.

Requirement scenarios
ISYS 1117 - Software Engineering
Analysis and Design
Online Tutorials

Interviewing
Copyright 2002 RMIT Computer
Science
All Rights Reserved

ISYS-1117
Fact finding techniques

JAD

Table Of Contents

et us now look at some types of

closed-ended questions:
There are five basic types of closedended questions to choose from. Each one is
briefly explained below, with examples
provided:

1.0 - Requirements Analysis - Prelude

1.1 - What is a requirement
2.0 - Requirement scenarios
3.0 - Fact finding techniques
3.1 - Interviewing
3.2 - JAD
3.3 - JAD & Questionnaire
4.0 - Specification & SRS
4.1 - SRS
5.0 - Functional vs Non-functional
requirements
6.0 - Specification Review
7.0 - References & Acknowledgments

1) Likert-scale: When you want to know respondents' feelings or

attitudes about something, consider asking a Likert-scale question.
The respondents must indicate how closely their feelings match the
question or statement on a rating scale. The number at one end of
the scale represents least agreement, or "Strongly Disagree," and
the number at the other end of the scale represents most
agreement, or "Strongly Agree." If the scale includes other words
at either end to further clarify the meaning of the numbers, it is
known as a Likert-style question. Example:
How important do you think standardized test scores are to a
fifth-grader's education (circle one number):
Not very
important
Extremely
important
1
2
3
4
5

2) Multiple-choice: When you want respondents to pick the best

answer or answers from among all the possible options, consider
writing a multiple-choice question. Multiple-choice questions are
easy to lay out on a written survey. Include specific directions
about how many answers to select directly after the question.
Example:
Why don't you use the school's cafeteria services? (circle one):
a.
It's too expensive.
b.
Serving times conflict with my class schedule.
c.
The location is inconvenient.
d.
The food quality is poor.
e.
Other (please explain):_______________
3) Ordinal: When you need all possible answers to be rank
ordered, ask an ordinal question. Example:
Please write a number between 1 and 5 next to each item below. Put
a 1 next to the item that is MOST important to you in selecting an
on-line university course. Put a 5 next to the item that is LEAST
important. Please use each number only ONCE.
___ a.
Availability of instructor for assistance.
___ b.
Tuition cost for the course.
___ c.
Ability to work in groups with other students.
___ d.
Quality and quantity of instructor feedback.
___ e.
Number of students enrolled.
4)Categorical: When the possible answers for a
question are categories, and each respondent must
"belong" in exactly one of them, ask a categorical
question.
5)Numerical: When the answer must be a real number, ask a
numerical question. Example: How old were you on your last
birthday?

How do I know which type to use?

Type of question

Best Used for...

Open-ended
Breaking the ice in an interview; when
respondents' own words are important;
when the surveyor doesn't know all the
possible answers.
Closed-ended
Collecting rank ordered data; when all
response choices are known; when
quantitative statistical results are desired.
Likert-scale
To assess a person's feelings about
something.
Multiple-choice
When there are a finite number of options
(remember to instruct respondents as to
the number of answers to select).
Ordinal
To rate things in relation to other things.
Categorical
When the answers are categories, and
each respondent must fall into exactly one
of them.
Numerical
For real numbers, like age, number of
months, etc.

Fact finding techniques

ISYS 1117 - Software Engineering
Analysis and Design
Online Tutorials

JAD
Copyright 2002 RMIT Computer
Science
All Rights Reserved

ISYS-1117
Interviewing

JAD & Questionnaire

Table Of Contents

AD is a structured process in which 10

to 20 users meet together for several
hours, days, weeks or months under
the direction of a skilled facilitator. This
technique was developed by IBM in 1970s.
It is often a very useful technique for
collecting information from the user. The
aims of a JAD session are the following:

1.0 - Requirements Analysis - Prelude

1.1 - What is a requirement
2.0 - Requirement scenarios
3.0 - Fact finding techniques
3.1 - Interviewing
3.2 - JAD
3.3 - JAD & Questionnaire
4.0 - Specification & SRS
4.1 - SRS
5.0 - Functional vs Non-functional
requirements
6.0 - Specification Review
7.0 - References & Acknowledgments

To identify the problem, propose elements of the solution and negotiate different
approaches to the problems uncovered.
To develop an initial set of user requirements in an atmosphere that is conducive to
the accomplishment of the goal.

So why do I need to know about JADs?

Ask your client what they want.

Client signs off on specifications.
You build and deliver the system according to the specifications.
Your client says they want something different.

How do you design a system that clients really want? You can't. You have to help clients
design the system they want. If you are telling business users how to solve their problems,
you are missing the boat. You have to establish a relationship with the client to get behind
what they are saying the problem is in order to discover the true underlying problem.

The real problem is typically very different from the one first perceived by the client.
Don't just be a problem solver...look deeper. Don't assume that one person ever knows
everything about a problem.

What is a JAD?
JAD Definition: Joint Application Development (JAD) is a management
process which helps IS work effectively with users to develop information
technology solutions that really work.
JAD Purpose: to define the project, design a solution, and monitor the
project until it reaches completion.
JAD Philosophy: The JAD process is based on four simple ideas:
1. People who actually do a job have the best understanding of that
job.
2. People who are trained in information technology have the best
understanding of the possibilities of that technology.
3. Information systems and business processes rarely exist in isolation - they transcend the confines of any single system or office and
effect work in related departments. People working in these related
areas have valuable insight on the role of a system within a larger
community.
4. The best information systems are designed when all of these groups
work together on a project as equal partners.
JAD Scope - The JAD should cover the complete development life cycle of
a system. The JAD is usually a 3 to 6 month well-defined project. For largescale projects, it is recommended that the project be approached
incrementally, and that separate JAD's be used for each increment.

Who is involved in a JAD?

Sponsor - this is the executive who charters the project, the system owner.
They must be high enough in the organization to be able to make decisions

and provide the necessary resources and support for the project.
Business Users - the intended users of the system being designed. They are
here because of their business expertise. There are two kinds of Business
Users; Real End Users and Big Picture Users.
Real End Users will have to use the new system to do their
jobs. Big Picture Users understand the standards and
methodologies of the business functions. It is important to
have both types of users. If you only have Big Picture Users
you will end up with a great theoretical model of how things
should work, but it may not work in practice. If you just have
Real End Users, you will get a good system for today, but it
may not work a year or two down the road.
Systems Analysts - Provide non-technical explanations that help other JAD
members understand and fully utilize the technology available. Monitor
design for ease of use/maintenance and adherence to standards. Provide
hardware/software development.
Important Question to Ask: Do I have all the affected customers/areas represented?

Roles of JAD Group Members

Project Sponsor - remember, this is the person who owns the business
process. Their support and participation is crucial to the success of the
JAD. In addition to the project responsibilities listed below, the project
sponsor and the lead analyst can share the role of Project Leader, being
equally responsible for the successful completion of the JAD.
Project Sponsor Responsibilities

ensure the right clients are part of the group

ensure there is enough technical staff support for the
project
ensure that software/hardware is purchased as needed
for the project
ensure that the clients are given time off from their
regular work to attend the JAD meetings and to
perform the tasks they are assigned by the JAD

(policy research, gathering information / opinions

from other client groups, documentation, testing)
assign and work on policy research
delegate tasks to clients who are in the group
ensure that the client tasks are done
assist in the selection of test cases
assist in the definition of the scope and functionality
assist in benchmarking against current systems and
external systems
help set up quality measures
evaluate whether the system is effective and efficient

Project Leader - the project leader can make or break the project.
They need to be committed wholeheartedly to the project, and to have a
background knowledge of the business area and current or related
information systems. They also need to be committed to the company, and
to understand the implications of the project within the context of company
goals. They need to be enthusiastic and objective. They need to be sensitive
to political issues and able to draw out the opinions of the quiet members of
the group, and to not allow any single individual to dominate the group.
Project Leader Responsibilities

work with project sponsor to ensure the right people

are in the group
ensure all roles for the group are filled
ensure that meetings are scheduled and publicized
with agendas
ensure that agendas are planned and followed
ensure that meeting notes are taken, and published by
the recordkeeper
edit the notes and make sure they are not a transcript
but a concise accurate summary of decisions made
(both pro and con) and issues discussed and actions to
do (make sure they are available historically if a new
member has to join in the middle of a project)
ensure that tasks are assigned and done, and that a
task list is planned and executed in the sequence that
it needs to be, with appropriate timelines
coordinate the technical efforts of the analysts on the
team
do research prior to the meetings to make sure
background information is gathered on the appropriate
agenda topics
facilitate the meetings effectively

Recordkeeper - The recordkeeper takes comprehensive notes during a

session, and then edits them into a concise summary of discussions and
decisions. It is important that the resulting notes NOT be transcription of
who said what. The role can be shared by various members of the team as
needed. Often a well-facilitated meeting will have a note taking
recordkeeper, and also someone who records points on an easel pad. The
easel pad serves as a ready reference to the group when summarizing
discussions, and for return reference on complex points. And it also is a
means for the recordkeeper to evaluate the accuracy and thoroughness of
their notes.
Recordkeeper Responsibilities

take accurate and thorough notes during the meeting

ask for clarification on points if anything is not clear
summarize and condense the notes after the session
ensure that the JAD leader and project sponsor or
other relevant people proof and edit the notes prior to
publishing
publish the notes for all current members of the team
and for any other interested parties
keep a history of the notes for the benefit of any
members who join the team in mid-project
remind the group if they contradict earlier decisions
and make sure they know they are in contradiction.

Timekeeper - The Timekeeper is responsible for keeping the meeting

running on time and helping the group use time wisely.
Timekeeper Responsibilities

makes sure the meeting begins and ends on time

helps the meeting stay on time for each topic on the
agenda
reminds the group that they need to end a discussion
in order to have time to summarize and create an
action plan in the final minutes of the meeting

Clients - Clients are here because this is a system they use. They
understand how this system is used in the real world. They will help the
group understand all the tasks handled by the system, correct any
misperceptions, search for oversights and supply details. Remember, no
detail is too small to mention. Sometimes minor details make a major
difference in the way the system should work.

Typical Client Responsibilities

describe the sequence of events in a business process

as it affects their office
describe the decisions that have to be made in a
business process
define the information that the process has to deal
with
define what is critical vs. what would be nice for the
first version of the system
bring up any problems that exist in the current process
or any opportunities for making it more efficient
research policy questions when a new business
procedure is being proposed
analyze if there are any obstacles to success in the
current environment of their office for implementing
the new system
create test cases for testing
run test scripts on the cases
give the developers feedback on the usability and
accuracy and effectiveness of the system in an
organized, documented way
help prepare documentation on how the system works
from a client's point of view
help prepare and implement training for other clients

All Team Members - have the following responsibilities:

Interviewing

Commitment to the team

Regular attendance
Actively listen
Actively participate
Identify concerns
Brainstorm ideas
Recommend solutions
Agree upon a design by consensus
Assist with project duties

JAD & Questionnaire

ISYS 1117 - Software Engineering

Analysis and Design
Online Tutorials

Copyright 2002 RMIT Computer

Science
All Rights Reserved

ISYS-1117
JAD

Specification & SRS

Table Of Contents

hecklist for getting a JAD started:

1.0 - Requirements Analysis - Prelude

1.1 - What is a requirement
2.0 - Requirement scenarios
3.0 - Fact finding techniques
3.1 - Interviewing
3.2 - JAD
3.3 - JAD & Questionnaire
4.0 - Specification & SRS
4.1 - SRS
5.0 - Functional vs Non-functional
requirements
6.0 - Specification Review
7.0 - References & Acknowledgments

1. Define the Project

The JAD Project Leader meets with the Project Sponsor to complete a JAD Project
Charter.
2. Form the JAD Group
The Project Leader and Project Sponsor form the JAD Group making sure you
have all affected areas represented. You will need a Project Sponsor, Project
Leader, Business Users and Systems Analysts. A JAD Group should have 8 or
fewer total members. It is hard to be effective with more than 15 members.
3. First JAD Meeting - Kick off Meeting
Your first JAD meeting may have the following agenda items:
Share problem definition and overall goal. Get consensus on these two
items.
Train each member of the new group on what a JAD Group is so they will
understand the purpose, the roles and how a JAD works.
Establish JAD Group expectations/responsibilities.
Determine meeting frequency, time and place.
Determine roles - Project Sponsor, Project Leader, Recordkeeper,
Timekeeper, Clients.
Continue holding JAD meetings approximately every week or every other
week until you have reached consensus on a design.

4. JAD Meetings - Planning, Analysis, Design Phase

Review the current process - map it out
Identify Problems/Challenges in the current process
Brainstorm solutions for those problems and challenges
Benchmark other organizations for possible solutions
Consider Buy vs. Build
Survey your customers for problems and ideas
Evaluate list of generated ideas
Determine your course of action - tasks to be accomplished
Develop your timebox - list of tasks, who is assigned and when each task is
due.
Present the Project Design to the Project Sponsor and Representative
Customers and Get the Thumbs Up
Communicate, Communicate, Communicate
5. JAD Meetings - Development, Execute, Finish Phase
Meet every 2 weeks to make sure the development stays on track
Agenda - how did we do on our goals?
Discuss problems and challenges
Make decisions jointly
Set goals for next meeting
Assign tasks
Assign as many of the project duties as possible to members of the JAD - this
helps build buy in and a feeling of ownership towards the project.

How do you know if your JAD is

successful?
Questions to ask

Are your meetings well attended?

Are all affected parties involved/aware of decisions being made?
Did you solve the true underlying problem?
Is your solution accepted and used by your clients?
Is the solution available on time?

Success Factors

A clear purpose shared by all team members - the project charter

A diverse team, representative of all areas effected by this project.
Every person in the group has equal responsibility and decision
making power.
Every idea is valuable. Throughout the JAD, listen and acknowledge
each idea and concern. Evaluating ideas during a brainstorming

session will shut down the creative process. The best idea may never
get said out of fear of being shot down.
Participation by everyone is very important. Encourage quieter
members to speak, they often have the best ideas. Don't allow 1 or 2
members to dominate. This is the facilitators responsibility as well
as the whole teams' responsibility.
Listen when others speak, don't interrupt or talk while others are
talking (side conversations may have great ideas...we don't want to
miss them).
Maintain a parking lot to record important issues that are not within
the scope of this project.
Don't hold meetings just to hold meetings. Only meet when there is
something substantial to talk about.
Don't let more than 3 or 4 weeks pass between meetings, you will
loose momentum. Remember, each meeting is a motivation for the
team to complete tasks assigned. It is no fun to come to a meeting
and admit you didn't finish your task.
Decisions are reached by consensus. We are here to create a win/win
solution...win/lose solutions aren't good enough. You can reach
consensus by giving everyone three options:
Thumbs up - I agree
Thumbs down - I disagree
Thumbs sideways - I can support this idea

Pitfalls:

Sponsor not really committed - no resources

Unclear goals or objectives - lack of direction
Too many or too few members
Not enough communication with outsiders affected by decisions
Timelines aren't kept
Project Creep - project grows beyond the original definition and scope
if this really needs to happen, it is time to rewrite the project charter
Meetings aren't well facilitated
don't have an agenda
don't stick to agenda
don't begin or end on time
feels like nothing is accomplished in the meeting - old items not within
scope keep getting revisited over and over
1 or 2 members dominate discussions

JAD Group Benefits

Communication, Communication, Communication

Build consensus and ownership

Improve design quality - combined knowledge = better solutions
Design cross-functional solutions
Helps project teams get focused and stay focused
Helps you get the right job done at the right time

Questionnaires
Questionnaires are often used when there is a large group of people from whom the
information is needed. Normally a questionnaire is for the outside use of the organization.
The reach and scope covered can be much wider as compared to other methods of fact
finding. The steps involved with this mode of fact-finding are:

Seleceting th right participants,

Desiging the questionnaire,
Administering the questionnaire and
Folllowing-up.

Designing the questionnaire is pretty much the same as designing an Interview-the only
difference is that while designing the questionnaire, it is important to keep in mind that
the questions should:

not be vague
self-explanatory
a proper mix of open, closed and probe category
be consistent in style
be as such that related questions are grouped together, so that it is easier for the
respondent.
begin with on some interesting note so that it motivates the respondent to answer
the whole questionnaire
not be very lengthy
provide anonymity to the user.

Just like a JAD or an interview session, a follow-up is important in order to gain from this
technique.
Have a look at a simple yet effective questionnaire - http://youtoo.agderforskning.no/questionnaire.htm

Checkpoints
1. What is Document Analysis?

2. Of the techniques mentioned above-which according to you will be the most

expensive?

JAD
ISYS 1117 - Software Engineering
Analysis and Design
Online Tutorials

Specification & SRS

Copyright 2002 RMIT Computer
Science
All Rights Reserved

ISYS-1117
JAD & Questionnaire

SRS

A specification that will not fit on one page of 8.5x11 inch paper cannot be understood. -Mark Ardis
Table Of Contents

efore we go ahead we have to

understand the following two terms:

Specifications
SRS

1.0 - Requirements Analysis - Prelude

1.1 - What is a requirement
2.0 - Requirement scenarios
3.0 - Fact finding techniques
3.1 - Interviewing
3.2 - JAD
3.3 - JAD & Questionnaire
4.0 - Specification & SRS
4.1 - SRS
5.0 - Functional vs Non-functional
requirements
6.0 - Specification Review
7.0 - References & Acknowledgments

Specification
A specification is a representation of a requirement in a manner that will enable a
developer to successfully implement it in software. It describes WHAT is to be
implemented in terms that are unambiguous, complete and testable. The representation
may be:

natural language
graphical or diagrammatic
executable specification (prototype)
mathematical representation

Of course one can write good specifications or bad ones. Since specifications are used as
reference points during the product/concept implementation, it is important that
specifications are:

Clear and Concise

Unambigious and
Understandable

Consider an example of a very nicely written clear cut specification.

Consider a common example of a word processor providing a select command,specified
in the following way- Selecting is the process for designating areas of your document that
you wnat to work on. Most editing and formatting actions require two steps: first you
select what you want to work on, such as text or graphics; then you initiate an
appropriate action.
SRS(Software Requirements Specification)
A Software Requirements Specification(SRS), or Requirements Analysis Document, is
produced at the end of the Requirements Elicitation and Analysis Stage. This document is
a major milestone in the software development process.

Checkpoint

Give a specification for the justify function in MICROSOFT WORD

No answer for this - try on your own

JAD & Questionnaire

ISYS 1117 - Software Engineering
Analysis and Design
Online Tutorials

SRS
Copyright 2002 RMIT Computer
Science
All Rights Reserved

ISYS-1117
Specification & SRS

Functional vs Non-functional requirements

Table Of Contents

he National Bureau of Standards,

IEEE(Standard No. 830-1984) and
the U.S. Department of Defense have
proposed a standard format of an SRS
document. A simplified version of this is as
follows:

1.0 - Requirements Analysis - Prelude

1.1 - What is a requirement
2.0 - Requirement scenarios
3.0 - Fact finding techniques
3.1 - Interviewing
3.2 - JAD
3.3 - JAD & Questionnaire
4.0 - Specification & SRS
4.1 - SRS
5.0 - Functional vs Non-functional
requirements
6.0 - Specification Review
7.0 - References & Acknowledgments

I.

Introduction
A.System reference
B.Overall description
C.Software project constraints
II. Information Description
A. Information content representation
B. Information flow representation
III.Functional Description
IV. Behavioural Description
V. Validation and Criteria
A.Performance bounds
B.Classes of tests
C.Expected software response
D.Special Considerations
VI. Bibliography
VII.Appendix
The Introduction states the goals and objectives of the software.
The Information Description provides a detailed description of the problem that the
software must solve.

The Functional Description provides a narrative for each of the functions required to
solve the problem.
The Behavioural Description examines the operation of software as a result of external
events and internally generated characteristics.
The Validation and Criteria is the most important and it describes the result of all the
tests and other considerations.
IEEE also states that a good SRS must be :

Unambiguous
Complete
Consistent
Modifiable
Verifiable
Traceable
Usable during the Operation and Maintenance phase

How can I write a GOOD SRS?

Always remember the following apsects and you would always end up with a very good
SRS:

SRS must say certain things. For example, software developed from an SRS that
fails to specify that error messages will be provided, will probably fail to satisfy
the customer.
It must say those things in a certain way. For example, software developed from an
SRS that fails to specify the format and content of error messages and instead is
developed from a vague and non-quantifiable requirement such as All error
messages will be helpful will probably be unsatisfactory as what is helpful for one
person can be a severe aggravation to another person.
SRS should NOT describe any design, verification, or project management details,
EXCEPT for required design constraints.

Checkpoint
1. What are some constraints that you can mention in a SRS document?
2. Outline some major difficulties that are encountered during analysis process?
3. What is the importance of having an SRS?

Specification & SRS

Functional vs Non-functional requirements

ISYS 1117 - Software Engineering

Analysis and Design
Online Tutorials

Copyright 2002 RMIT Computer

Science
All Rights Reserved

ISYS-1117
SRS

Specification review

"Success is more a function of consistent common sense than it is of genius. --An Wang
Table Of Contents
lease understand that Functional
requirements capture the intended
behavior of the system. This behavior
may be expressed as services, tasks or
functions the system is required to perform.
In product development, it is useful to
distinguish between the baseline
functionality necessary for any system to
compete in that product domain, and
features that differentiate the system from
competitors products, and from variants in
your companys own product line/family.

1.0 - Requirements Analysis - Prelude

1.1 - What is a requirement
2.0 - Requirement scenarios
3.0 - Fact finding techniques
3.1 - Interviewing
3.2 - JAD
3.3 - JAD & Questionnaire
4.0 - Specification & SRS
4.1 - SRS
5.0 - Functional vs Non-functional
requirements
6.0 - Specification Review
7.0 - References & Acknowledgments

Features may be additional functionality, or differ from the basic functionality along some
quality attribute (such as performance or memory utilization). One strategy for quickly
penetrating a market is to produce the core, or stripped down, basic product, adding
features to variants of the product to be released shortly thereafter. This release strategy is
obviously also beneficial in information systems development, staging core functionality
for early releases and adding features over the course of several subsequent releases. In
many industries, companies produce product lines with different cost/feature variations
per product in the line, and product families that include a number of product lines
targeted at somewhat different markets or usage situations. What makes these product
lines part of a family, are some common elements of functionality and identity. A
platform-based development approach leverages this commonality, utilizing a set of
reusable assets across the family. These strategies have important implications for
software architecture. In particular, it is not just the functional requirements of the first
product or release that must be supported by the architecture. The functional requirements
of early (nearly concurrent) releases need to be explicitly taken into account. Later
releases are accommodated through architectural qualities such as extensibility,
flexibility, etc. The latter are expressed as non-functional requirements. Use cases have
quickly become a widespread practice for capturing functional requirements. This is
especially true in the object-oriented community where they originated, but their
applicability is not limited to object-oriented systems.

However, Non-Functional Requirements (NFRs) of a system are attributes and

characteristics of the system.
Think of functional requirements as verbs, and NFRs or attributes as adjectives or
adverbs. Two products could have exactly the same functions, but their attributes can
make them entirely different products. A Rolls Royce has more or less the same functions
as a Yugo, but many, many different attributes.

Some examples of a non-functional requirement can be:

Performance - throughput features of sytem such as response time

Useability features - easy to learn and use
Efficiency - minimal use of computing resources
Reliability features - eg. long mean-time between failures; availability, correctness
Security features - eg. prevents unauthorized access to programs and data
Robustness - works in the presence of invalid input, faults, stressful conditions
Adaptability - reusable in other environments, for other problems
Scalability - works with large data sets
Portability - easily modified to work on different platforms
Modifiability - easily extended with new features

As per L. Chung, B. A. Nixon, E. Yu and J. Mylopoulos Non-Functional Requirements

in Software Engineering presents a systematic and pragmatic approach to `building
quality into' software systems. Systems must exhibit software quality attributes, such as
accuracy, performance, security and modifiability-as mentioned above. However, such
non-functional requirements (NFRs) are difficult to address in many projects, even
though there are many techniques to meet functional requirements in order to provide
desired functionality. This is particularly true since the NFRs for each system typically
interact with each other, have a broad impact on the system and may be subjective. To
enable developers to systematically deal with a system's diverse NFRs, this book presents
the NFR Framework. Structured graphical facilities are offered for stating NFRs and
managing them by refining and inter-relating NFRs, justifying decisions, and determining
their impact. Since NFRs might not be absolutely achieved, they may simply be satisfied
sufficiently. To reflect this, NFRs are represented as `softgoals', whose interdependencies
such as tradeoffs and synergy, are captured in graphs. The impact of decisions is
qualitatively propagated through the graph to determine how well a chosen target system
satisfies its NFRs. Throughout development, developers direct the process, using their
expertise while being aided by catalogues of knowledge about NFRs, development
techniques and tradeoffs, which can all be explored, reused and customized. NonFunctional Requirements in Software Engineering demonstrate the applicability of the
NFR Framework to a variety of NFRs, domains, system characteristics and application
areas.

SRS
ISYS 1117 - Software Engineering
Analysis and Design
Online Tutorials

Specification review
Copyright 2002 RMIT Computer
Science
All Rights Reserved

ISYS-1117
Functional vs Non-functional requirements

References & Acknowledgment

Reviewing has one advantage over suicide: in suicide you take it out on yourself; in
reviewing you take it out on other people. George Bernard Shaw (1856 - 1950)
Table Of Contents

he final stage of our specification

process is the Specification Review
Stage. Review is conducted by both
software developer and customer. Extreme
care should be taken in this step as it forms
the foundation for design and subsequent
activities. Review is conducted at
macroscopic levels and the following
aspects are covered:

Do the functions meet the scope?

Are the constraints recognised?

1.0 - Requirements Analysis - Prelude

1.1 - What is a requirement
2.0 - Requirement scenarios
3.0 - Fact finding techniques
3.1 - Interviewing
3.2 - JAD
3.3 - JAD & Questionnaire
4.0 - Specification & SRS
4.1 - SRS
5.0 - Functional vs Non-functional
requirements
6.0 - Specification Review
7.0 - References & Acknowledgments

Can the system be partitioned effectively?

Can the system be developed in stages?
Are diagrams clear?
Do inconsistencies, ommission or redundancy exist?
Is the customer contact complete?
How are planning estimates affected?

In order to develop answers to many of the above questions, it might be necessary to go to

a detailed level, each individual specification analysed for hidden meanings, ambiguities
and problems. In that case one might look for

Missing requirements
Consistency among requirements
Requirements that are ambiguous
Requirements that are not correct
The value of each requirement to the customer
Factors that will increase project risk
Look for statements that imply certainty (eg always,every,all,none,etc.), then ask
for proof

Once the review has been completed, the software is signed off by both client and
developer. The SRS becomes the contract for software development. Changes in
requirements requested after the specification is finalised are not eliminated, but the client
knows that each after-the-fact change is an extension of software scope and therefore can
increase cost and/or protract the schedule.

Functional vs Non-functional requirements

ISYS 1117 - Software Engineering
Analysis and Design
Online Tutorials

References & Acknowledgement

Copyright 2002 RMIT Computer
Science
All Rights Reserved

ISYS-1117

Table Of Contents
1.0 - Requirements Analysis - Prelude
1.1 - What is a requirement
2.0 - Requirement scenarios
3.0 - Fact finding techniques
3.1 - Interviewing
3.2 - JAD
3.3 - JAD & Questionnaire
4.0 - Specification & SRS
4.1 - SRS
5.0 - Functional vs Non-functional
requirements
6.0 - Specification Review
7.0 - References & Acknowledgments

The following books were useful during the preparation of this material:

Systems Analysis and Design -- Dennis Wixom

Software and its development-Joseph M.Fox -- Prentice Hall
Software State-of-Art :Selected Papers -- Dorset House Publishing
Fundamentals of Software Engineering -- Carlo Ghezzi,Mehdi jazayeri and Dino
Mandrioli--Prentice Hall
CASE-IEEE-2nd Ed
Sofware Engineering -- by Roger S. Pressman -McGraw Hill International Editions

Following websites were refereed to :

ISYS1117 Subject Home Page

http://www.utdallas.edu/~chung/BOOK/book.html
http://www.bredemeyer.com/pdf_files/NonFunctReq.PDF
The icons have been picked up from this website

Written by Shekhar Kalra.

Reviewed by Laura Thomson & Clemens Mayr.

ISYS 1117 - Software Engineering

Analysis and Design
Online Tutorials

Copyright 2002 RMIT Computer

Science
All Rights Reserved