the requirements gathering process

3F s.a.s di Filippo Fadda

3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)marzo 2011 2

Software Development Lifecycle

A software development lifecycle, also known as software development process, is a structure imposed on the development of a software product.

Analysis

Quality Gateway

Design

Construction

Testing

Production Deployment

Staging Deployment

Maintenance


Specification Document

Contents

● Stakeholders

● Purpose of the Product

● Users of the Product

● Commercially available Off-The-Shelf (COTS) Solutions

● Risks

● Estimated Costs

● Use Cases

● Requirements

– Functional Requirements

– Non-functional Requirements

● Waiting Room

● Project Dictionary



Stakeholders

Who are they?

Stakeholders are people who have an interest in the product.

The client is the person who pays for the development of the product. So the client, maybe in a person that works for it, is a stakeholder.

The customer buys the product once is developed. You may already know the names of your customers, or they maybe hundreds or thousands of unknown people who might some day put down their money and walk out of the store with the product under their arm. If you know the customer, or the customers, you should involve them into the project, because they are stakeholders.



Stakeholders

Project Manager and Product Manager are the people who manage the day-to-day project effort.

Developers who will be part of the building effort for the product. It's not necessary have all the developers involved, but only some of them.

The marketing department of your company probably needs to be involved into the requirements gathering process.

Also the legal stuff can be useful. So, for the legal requirements, you should consult your lawyer.

People who don't want the product should have the opportunity to express their perplexities.


Project Blastoff

The blastoff is a meeting where the principals stakeholders work together until they achieved the blastoff's objectives.

Stakeholders are the people who have a vested interest in the product.

Some of the principal stakeholders are: the client, the main users, the lead developers, technical and business experts, and other key people.

The blastoff deliverables lay the foundation for the project. The blastoff delivers knowledge.

The project blastoff is about knowing. Knowing what you want the product to do for you, and what it will cost to build it. Knowing the scope of the work, in order to gather the requirements for the product.



Purpose of the Product

The second chapter of a specification document deals with the fundamental reason that your client wants to build a product. That is, it describes the business problem that the client faces and how the product will solve that problem.

Maybe the client wants automize a process that is manual, or he wants reach a new market, but he hasn't the right product for it. Or simply he wants improve an existence software or build a new version from scratch.

So, which are the goals of the product? The goals are determined at blastoff time. You must ensure the goals are reasonable, attainable, simply stated, worthwhile, and carry and measurement, so that you can test the delivered product to ensure that it satisfies the goal.



Purpose of the Product

If the goal does not have these properties, then history demonstrates that it is unlikely the project will deliver anything useful.

The goal is used throughout the requirements gathering activity. Each of the requirements that you gather must contribute, even if indirectly, to the goal.

Requirements that don't contribute are not relevant, and should be discarded.



Users of the Product

Users are the people who will interact directly with your product. In this document section, you identify all the people who might conceivably make use of the product.

The users are determined when you identify the product boundary during trawling.

The users determine the usability requirements. That is, you write usability requirements to suit the characteristics of the users.

The purpose of identifying the user categories is so that you can understand the work that they do. After all, your product is intended to help with this work.

Users are the actors will interact with your product features.




At the starting point is useful make a list of the roles that people might be play in connection with your product:

● What are the jobs of the people who might use your product?

● What other roles might people have?

● Where will people be when they are using your product?

● What are the nationalities of the people who might use your product?

● Are there any organizations who might use your product?




For every users category might be useful write down a their:

● Technology experiences

● Intellectual abilities

● Attitude to job

● Attitude to technology

● Education

● Linguistic skills

● Age

● Gender



Commercially available Off-The-Shelf (COTS) Solutions

This section of the specification document looks for available solutions and gives a summary of their applicability to the requirements.

Is there a ready-made product or a commercial off-the-shelf software that could be bought?

Can ready-made components be used for this product?

Is there something that we could copy?

Is there some open source project that we can fork?



Risks

All project involve risks.

In this section of the specification you will write down a list of the most likely and most serious risks for your project.

Against each risks include the probability of that risk becoming a problem and any contingency plans.



Estimated Costs

The other cost of requirements is the amount of time and money, the effort, that you have to spend building them into the product. Once the specification document is complete, you can use one of the estimating methods to assess the cost, and express this as monetary amount or time to build.

The important issue is that your estimate is based on metrics that are directly related to the requirements. If you have specified the requirements in the way we are going to see, you will have:

● Number of product use cases

● Number of requirements

● Estimated number of function points


Trawling for Requirements

Let's trawling

Trawling is a method of fishing that involves pulling a fishing net through the water behind one or more boats. The net that is used for trawling is called a trawl.

The boats that are used for trawling are called trawlers. Trawling can be carried out by one trawler or by two trawlers fishing cooperatively (pair trawling).

The term trawling comes from Steve McMenamin and it evokes the nature of what we are doing here: running a net through the organization to catch every possible requirement.

The trawling analogy is appropriate because the trawlers catch more fish than they really want. If the skipper catch salmons and he doesn't want them, he can always throw them back into the water.

Any inappropriate requirements that get caught up in your net will be filtered out by the Quality Gateway.



The Requirements Analyst

The analyst is a translator. He has to understand what the user is saying about the work, and translate this into a specification for a product.

The requirements analyst has to inject something new into the process: his vision of what the product might be.

In other words the requirements are not simply the passive interpretation of an existing piece of work, but contain inventions that will make the work easier, better, more interesting and more pleasant.



The Requirements Analyst

The analyst observe and learn the work, and understand it from the point of view of the user.

The analyst must filter the description to strip away any of the current technology or way of doing things in order to see the essence of the work, not its incarnation.

Invents better way to do the work.

Record the results in the form of requirements specification, and analysis models.



What are Requirements?

Requirements are things that you should discover before starting to build your product. A requirement is something that the product must do.

It's fairly obvious that the requirements must be known before constructing the product.

Design translates the requirements into a plan to build some physical reality that will, in the real world, do what is required.

The design process needs requirements as input. Designing without requirements is no more than inventing without knowing if the invention is useful.



Discovering the Requirements

It is important to the success of the product that design decisions are not taken before the relevant requirements are known. Steve McConnell reports that 60% of error exist as design time.

Users are conscious of some requirements and they will bring them up early. There are others that we call unconscious requirements, that are so ingrained into the users' work, that they have forgotten they exist.

Undreamed of requirements are there because the users do not realize that they are possible. Whatever the reason, part of the analyst's responsibility is to bring these requirements to the surface.

All the requirements must be captured during the trawling activity.



Models, Mockups and Prototypes

The first part of requirements trawling is observing the work. I suggest when you are doing this, you are not just a passive onlooker, but actively understand the work. The most effective way of doing this is by building a model.

You use models to understand the work. You can't build a model without understanding the subject of your model, but the modeling activity makes you ask all the right questions. When the model is finished, it means that you have understood the subject.

You use models to record the work and to demonstrate your understanding of it. Most importantly, since the model is a common language between you and your user, both of you can agree that you have the identical understanding of the work.



Apprenticing

Apprenticing is a wonderful way to observe the real work. It is based on the idea of masters and apprentices. In this case, the requirements analyst is the apprentice and the user is the master craftsman. The apprentice sits with the master to learn the job by observation, asking questions and doing some of the work under the master's supervision.

To get the user to describe the work, you must not take him away from his work. Rather, the apprentice sits alongside the user and receives a running commentary on the work as it happens. Each actions is explained, and if not clear, the apprentice asks questions: Why did you do that? What does this mean? How often this happen? What happens if this piece of information is not here?

So while the apprentice is learning the work by seeing the same task performed many times, he is also looking past how the user does the work, to see the underlying essence of the work.



Interview the Users

Interviewing the users is the traditional approach to requirements gathering. However, used on its own it may not be the most effective, because it commonly expects the users to know and to be able to tell all their requirements. I suggest that interviews are not the sole method of gathering, instead use them in conjunction with other techniques.

Mind Maps

We use mind maps all the time. We use them to take notes, for planning, for summarizing, for exploring ideas. Our brains store information by making associations. We link each new piece of information to something, or some things, that we already know.



Brainstorming

Invention is part of the requirements process. The product that the requirements analyst specifies should include new and better ideas for improving the work. Brainstorming is a method for generating new ideas. Brainstorming takes advantage of the group effect. That is, you enclose group of bright, willing people, and ask them to generate as many ideas as possible for the new product.

Participants in the brainstorm should come from as wide a range of disciplines. For the moment suspend judgement, evaluation and criticism. Simply record requirements as they are generated.

Produce lots of ideas. Come up with as many ideas as possible. Quantity will in time produce quality.

Write every idea down, without censoring. Ideas disappear faster than water evaporates unless written down.



Snow Cards

William Pena, an architect, coined the term snow card. Pena's architectural firm used white cards to record requirements and issues relating to buildings they were designing – hence the term snow.

We use cards when we are interviewing clients and users to record requirements as we hear them. Initially the requirement is not fully formed, so we might simply capture the description and the source.

As time as progresses and the requirements become better understood, the components of the requirement are progressively completed on the card.

A snow card or shell is a container for an individual requirement.



Volere Shell



Requirement Number

Each requirement must be uniquely identified. This reason is straightforward: requirements must be traceable throughout the development of the product, so it is convenient and logical to give each requirement a unique number.

Use Case Number

During later analysis, you will analyze each business event and use case separately. Thus it is convenient to be able to collect together all the requirements for that part of the work.



Requirement Type

There are two main requirement's types:

● Functional

● Not-functional

We will see them later.



Name or Description

This is a brief description for the requirement.

Rationale

The rationale is the reason behind the requirement existence. It tells why the requirement is important, what contribution it makes to the product's purpose. Adding a rationale to the requirement helps you to clarify and understand it. Having this justification of the requirement helps you to assess its importance when you are testing for gold plating in the Quality Gateway activity.

Source or Originator

The source is the name of the person who raised the requirement.



Fit Criteria

The fit criteria are quantified goals that the solution has to meet, they are acceptance criteria. The tester will use it to determine if the requirement has been met.

Customer Satisfaction and Dissatisfaction

The satisfaction ranking is the measure of how happy the client will be if you successful deliver the requirement. The scale ranges from 1 to 5, when 1 means the client is not happy at all, and 5 that is extremely happy.

Same for dissatisfaction where 1 indicates that the client is unconcerned about the requirement delivery, and 5 that your client will be really angry if you don't implement the requirement.



Dependencies

Dependencies are other requirements that have an impact on this one.

Conflicts

Conflicts are other requirements that contradict this one or make this one less feasible.

Supporting Materials

Do not attempt to put everything in the specification. There will always be other material that is important to the requirements, and it may be simply referenced by this item.

History

This is the place to record the date that the requirement was first raised, dates of changes, date of deletion, date of passing throught the Quality Gateway, and so on.



Use Cases

A use case is a description of an action performed by a user (or actor) in a software system. The user or actor might be a person or something more abstract, such as an external software system or manual process.

Use cases are a software modeling technique that helps developers determine which features to implement and how to gracefully resolve errors.

Within systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in SysML requirement diagrams or similar mechanisms.

Specification Document Use Cases

Main


Document Management


Community Tools



Use Cases listDocument Management 5

Edit Management 5-1

Structure Management 5-2

Page Settings Management 5-3

Print Management 5-4

View Management 5-5

Insert Elements Management 5-6

Offline Editing Management 5-7

Text Format Management 5-8

Track Changes Management 5-9

Table Management 5-10

Table Of Contents Management 5-11

List Management 5-12

Form Management 5-13

Link Management 5-14

Image Management 5-15

Hint Management 5-16

Bookmark Management 5-17

Note Management 5-18

Highlight Management 5-19

CVS Management 5-20



Use Cases listPermission Management 6

Customization Management 7

Layout Customization Management 7-1

Toolbar Customization Management 7-2

Menu Customization Management 7-3

Message Management 8

Folder Management 9

Audit Management 11

Advertise Management 12

Users Management 13

Community Partecipation 14

Forum Partecipation 14-1

Poll Managemet 14-2

Pending Content Management 15

Community Members Management 16

Security Group Management 17

Community Customization Management 18

Community Management 19

Policy Management 20

Root Management 21

Space Management 22



Requirements

Functional Requirements

Functional requirements are things that product must do. That is, the functional requirements describe functions or actions that are to be part of the product.

Non-functional Requirements

Non functional requirements are the properties that the product must have.



Non-functional Requirements' Types

● Look and Feel Requirements

● Usability Requirements

● Speed Requirements

● Capacity Requirements

● Operational Requirements

● Maintainability and Portability Requirements

● Security Requirements

● Cultural and Political Requirements

● Legal Requirements


Quality Gateway

Check Point

The Quality Gateway is the single point that every requirement must pass through before it can become a part of the specification. QG ensures a rigorous specification by testing each requirement for completeness, correctness, measurability, absence of ambiguity ad several other qualities before each requirement can be added to the specification.

Why do we need a gateway? Consider the life that a requirement leads before it arrives at the QG: the requirement could have come from anywhere. You have used a variety of trawling techniques to discover the requirements.

Your concern is to capture all the requirements and not to miss anything. The resulting potential requirements are in a variety of forms and states of completion, which makes them difficult to review. At this stage we call them potential requirements.


Quality Gateway

Using the Gateway

The writing process applies the shell to the potential requirements and puts them into a consistent form. Now we can call them formalized potential requirements.

When a formalized potential requirement arrives at the QG it should be complete enough to undergo the tests to determine whether it should be accepted into the specification or excluded. If it is excluded, then it is returned to its source (originator) for clarification, revision or discarding.

To pass through the QG and be included in the specification, a requirement must pass a number of tests. Those tests ensure that the requirements are complete and accurate, and do not cause problems by being unsuitable for the design and implementation stages later in the project.


Quality Gateway

Testing Completeness

The requirements shell is a container for an individual requirement. The shell identifies the component parts of a requirement. You can use the shell to help you test whether a requirement is complete.

Are there any missing components?

Test each component of the requirement and, from the point of view of each stakeholder, ask: it is possible to misunderstand this?

There are, however, times when the components are not all necessary. For example, sometimes the Description makes it obvious why the requirement is important. In that case there would be no point in writing the Rational. Sometimes there are not Supporting Materials and so on.


Quality Gateway

Testing Traceability

To make sure each of your requirements is traceable it must have:

● A unique identifier

● The type of requirement

● Reference to the Use Case that contain the requirement

● Requirement's dependencies

● References to other requirements that are in conflict

● Consistent use of terminology


Quality Gateway

Testing Fit Criteria

The fit criterion is a measurement of the requirement that enables the testers to determine, without recourse to subjective judgements, whether the deliver solution meets, or fits, the requirement.

Is it essential that each requirement has a fit criterion. Any requirement that has not one must be considered incomplete.

Reject any requirements that don't have a valid fit criterion.


Quality Gateway

Viable Within Constraints

Do you have the technological skills to build the requirement?

Have you the time and the money to build the requirement?

Is the requirement acceptable to all stakeholders?

Do any partner applications or the expected work environment contradict the requirement?


Quality Gateway

Customer Value

The customer satisfaction/dissatisfaction ratings attached to each requirement indicate the value that the customer apply to it.

The satisfaction rating is a measure of how happy the customer will be if you successful deliver an implementation of the requirement. Instead the dissatisfaction rating measures the amount of unhappiness the customer will feel if you don't successfully deliver the requirement.

Gold Plating

The term gold plating comes from gold plated bathroom taps. Some people like to have gold plated taps. The water doesn't come out of the gold pated tap any better than it does from a chrome plated one. The difference is that the gold plated tap costs more.


Quality Gateway

Requirements Creep

Requirements creep may refer to requirements that enter into the specification after the collecting process is supposed to be finished. The product in fact keeps evolving. However, there is stage of the project when you decide that you are going to go ahead and build the product. The requirements that happen after this stage are the ones considered to be requirements creep.

Requirements creep has gained itself a bad name, usually because of the disruption to the schedules, and the bloated costs of product delivery.

Firstly, most creep comes about because the requirements were never gathered properly in the first place.



Waiting Room

Waiting room is for requirements that cannot, for one reason or another one, be part of the initial release of the product.

Your users and client know that the requirements are not forgotten, but merely parked until they can be incorporated in a future release of the product.



Project Dictionary

Names are important. During the blastoff you begin to collect and record the names that are used by the project. Each project or product has names that are particular to it. This is the terminology that you are trying to capture along with an agreed meaning.

Record the names in the project dictionary section of the specification document. This is a glossary that serves as a reference point for the project. It's impressive how many misunderstandings are caused when there is not a central glossary available.

This recording process never finish. During the trawling phase or when you collect new requirements, you will discover new names, that you must add to the project dictionary.