3F

s.a.s di Filippo Fadda
Software Development Lifecycle
A software development lifecycle, also known as software
development process, is a structur...
Specification Document
Contents
●

Stakeholders

●

Purpose of the Product

●

Users of the Product

●

Commercially avail...
Specification Document
Stakeholders
Who are they?
Stakeholders are people who have an interest in the product.
The client ...
Specification Document
Stakeholders
Project Manager and Product Manager are the people who
manage the day-to-day project e...
Project Blastoff
The blastoff is a meeting where the principals stakeholders work
together until they achieved the blastof...
Specification Document
Purpose of the Product
The second chapter of a specification document deals with the
fundamental re...
Specification Document
Purpose of the Product
If the goal does not have these properties, then history
demonstrates that i...
Specification Document
Users of the Product
Users are the people who will interact directly with your product. In
this doc...
Specification Document
Users of the Product
At the starting point is useful make a list of the roles that people
might be ...
Specification Document
Users of the Product
For every users category might be useful write down a their:
●

●

Intellectua...
Specification Document
Commercially available Off-The-Shelf (COTS)
Solutions
This section of the specification document lo...
Specification Document
Risks
All project involve risks.
In this section of the specification you will write down a list of...
Specification Document
Estimated Costs
The other cost of requirements is the amount of time and money,
the effort, that yo...
Trawling for Requirements
Let's trawling
Trawling is a method of fishing that involves pulling a fishing net
through the w...
Trawling for Requirements
The Requirements Analyst
The analyst is a translator. He has to understand what the user is
sayi...
Trawling for Requirements
The Requirements Analyst
The analyst observe and learn the work, and understand it from the
poin...
Trawling for Requirements
What are Requirements?
Requirements are things that you should discover before starting to
build...
Trawling for Requirements
Discovering the Requirements
It is important to the success of the product that design decisions...
Trawling for Requirements
Models, Mockups and Prototypes
The first part of requirements trawling is observing the work. I
...
Trawling for Requirements
Apprenticing
Apprenticing is a wonderful way to observe the real work. It is
based on the idea o...
Trawling for Requirements
Interview the Users
Interviewing the users is the traditional approach to requirements
gathering...
Trawling for Requirements
Brainstorming
Invention is part of the requirements process. The product that the
requirements a...
Trawling for Requirements
Snow Cards
William Pena, an architect, coined the term snow card. Pena's
architectural firm used...
Trawling for Requirements
Volere Shell

marzo 2011

3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'...
Trawling for Requirements
Requirement Number
Each requirement must be uniquely identified. This reason is
straightforward:...
Trawling for Requirements
Requirement Type
There are two main requirement's types:
●

Functional

●

Not-functional

We wi...
Trawling for Requirements
Name or Description
This is a brief description for the requirement.

Rationale
The rationale is...
Trawling for Requirements
Fit Criteria
The fit criteria are quantified goals that the solution has to meet,
they are accep...
Trawling for Requirements
Dependencies
Dependencies are other requirements that have an impact on this
one.

Conflicts
Con...
Specification Document
Use Cases
A use case is a description of an action performed by a user
(or actor) in a software sys...
Use Cases

Specification Document

Main
Specification Document

Use Cases
Document Management
Use Cases

Specification Document
Community Tools
Specification Document
Use Cases list
Document Management

5

Edit Management
Structure Management

5-2

Page Settings Man...
Specification Document
Use Cases list
Permission Management

6

Customization Management

7

Layout Customization Manageme...
Specification Document
Requirements
Functional Requirements
Functional requirements are things that product must do.
That ...
Specification Document
Non-functional Requirements' Types
●

●

Usability Requirements

●

Speed Requirements

●

Capacity...
Quality Gateway
Check Point
The Quality Gateway is the single point that every requirement
must pass through before it can...
Quality Gateway
Using the Gateway
The writing process applies the shell to the potential requirements
and puts them into a...
Quality Gateway
Testing Completeness
The requirements shell is a container for an individual requirement.
The shell identi...
Quality Gateway
Testing Traceability
To make sure each of your requirements is traceable it must have:
●

●

The type of r...
Quality Gateway
Testing Fit Criteria
The fit criterion is a measurement of the requirement that enables
the testers to det...
Quality Gateway
Viable Within Constraints
Do you have the technological skills to build the requirement?
Have you the time...
Quality Gateway
Customer Value
The customer satisfaction/dissatisfaction ratings attached to each
requirement indicate the...
Quality Gateway
Requirements Creep
Requirements creep may refer to requirements that enter into the
specification after th...
Specification Document
Waiting Room
Waiting room is for requirements that cannot, for one reason or
another one, be part o...
Specification Document
Project Dictionary
Names are important. During the blastoff you begin to collect and
record the nam...
Upcoming SlideShare
Loading in …5
×

The Requirements Gathering Process

1,181 views

Published on

A presentation of the Volere Requirements Process.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,181
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
31
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The Requirements Gathering Process

  1. 1. 3F s.a.s di Filippo Fadda
  2. 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 Staging Deployment Testing Production Deployment Maintenance marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 2
  3. 3. 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 ● ● marzo 2011 Waiting Room Project Dictionary 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 3
  4. 4. Specification Document 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 4
  5. 5. Specification Document 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 5
  6. 6. 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 6
  7. 7. Specification Document 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 7
  8. 8. Specification Document 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 8
  9. 9. Specification Document 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 9
  10. 10. Specification Document Users of the Product 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? ● ● marzo 2011 What are the nationalities of the people who might use your product? Are there any organizations who might use your product? 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 10
  11. 11. Specification Document Users of the Product For every users category might be useful write down a their: ● ● Intellectual abilities ● Attitude to job ● Attitude to technology ● Education ● Linguistic skills ● Age ● marzo 2011 Technology experiences Gender 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 11
  12. 12. Specification Document 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? marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 12
  13. 13. Specification Document 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 13
  14. 14. Specification Document 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 requirements ● marzo 2011 Number of product use cases Estimated number of function points 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 14
  15. 15. 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 15
  16. 16. Trawling for Requirements 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 16
  17. 17. Trawling for Requirements 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 17
  18. 18. Trawling for Requirements 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 18
  19. 19. Trawling for Requirements 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 19
  20. 20. Trawling for Requirements 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 20
  21. 21. Trawling for Requirements 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 21
  22. 22. Trawling for Requirements 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 22
  23. 23. Trawling for Requirements 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 23
  24. 24. Trawling for Requirements 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 24
  25. 25. Trawling for Requirements Volere Shell marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 25
  26. 26. Trawling for Requirements 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 26
  27. 27. Trawling for Requirements Requirement Type There are two main requirement's types: ● Functional ● Not-functional We will see them later. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 27
  28. 28. Trawling for Requirements 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 28
  29. 29. Trawling for Requirements 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 29
  30. 30. Trawling for Requirements 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 30
  31. 31. Specification Document 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 31
  32. 32. Use Cases Specification Document Main
  33. 33. Specification Document Use Cases Document Management
  34. 34. Use Cases Specification Document Community Tools
  35. 35. Specification Document Use Cases list Document Management 5 Edit Management 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 marzo 2011 5-1 5-20 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 35
  36. 36. Specification Document Use Cases list Permission 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 Community Members Management 16 Security Group Management 17 Community Customization Management 18 Community Management 19 Policy Management 20 Root Management 21 Space Management marzo 2011 15 22 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 36
  37. 37. Specification Document 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 37
  38. 38. Specification Document Non-functional Requirements' Types ● ● Usability Requirements ● Speed Requirements ● Capacity Requirements ● Operational Requirements ● Maintainability and Portability Requirements ● Security Requirements ● Cultural and Political Requirements ● marzo 2011 Look and Feel Requirements Legal Requirements 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 38
  39. 39. 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 39
  40. 40. 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 40
  41. 41. 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 41
  42. 42. Quality Gateway Testing Traceability To make sure each of your requirements is traceable it must have: ● ● The type of requirement ● Reference to the Use Case that contain the requirement ● Requirement's dependencies ● References to other requirements that are in conflict ● marzo 2011 A unique identifier Consistent use of terminology 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 42
  43. 43. 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 43
  44. 44. 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? marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 44
  45. 45. 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 45
  46. 46. 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 46
  47. 47. Specification Document 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 47
  48. 48. Specification Document 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. marzo 2011 3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL) 48

×