clipped from www.waterlootech.tvGet Clipmarks - The easiest way to email text, images and videos you find on the web.
Tuesday, August 26, 2008
UML-Class Diagrams
Source: www.agilemodeling.com
UML 2 Class Diagrams
| UML 2 class diagrams are the mainstay of object-oriented analysis and design. UML 2 class diagrams show the classes of the system, their interrelationships (including inheritance , aggregation, and association), and the operations and attributes of the classes. Class diagrams are used for a wide variety of purposes, including both conceptual/domain modeling and detailed design modeling. Although I prefer to create class diagrams on whiteboards because simple tools are more inclusive most of the diagrams that I'll show in this article are drawn using a software-based drawing tool so you may see the exact notation. |
In this article I discuss:
1. Conceptual Class Diagrams
Figure 1 depicts a start at a simple UML class diagram for the conceptual model for a university. Classes are depicted as boxes with three sections, the top one indicates the name of the class, the middle one lists the attributes of the class, and the third one lists the methods. By including both an attribute and a method box in the class I'm arguably making design decisions in my model, something I shouldn't be doing if my goal is conceptual modeling. Another approach would be to have two sections, one for the name and one listing responsibilities. This would be closer to a CRC model (so if I wanted to take this sort of approach I'd use CRC cards instead of a UML class diagram). I could also use class boxes that show just the name of the class, enabling me to focus on just the classes and their relationships. However, if that was my goal I'd be more likely to create an ORM diagram instead. In short, I prefer to follow AM's Apply the Right Artifact(s) practice and use each modeling technique for what it's best at.
Figure 1. Sketch of a conceptual class diagram.
Enrollment is an associative class, also called a link class, which is used to model associations that have methods and attributes. Associative classes are typically modeled during analysis and then refactored into what I show in Figure 2 during design (Figure 2 is still a conceptual diagram, albeit one with a design flavor to it). To date, at least to my knowledge, no mainstream programming language exists that supports the notion of associations that have responsibilities. Because you can directly build your software in this manner, I have a tendency to stay away from using association classes and instead resolve them during my analysis efforts. This is not a purist way to model, but it is pragmatic because the other members on the team, including project stakeholders, don't need to learn the notation and concepts behind associative classes.
Figure 2 depicts a reworked version of Figure 1, the associative class has been resolved. I could have added an attribute in the Seminar class called Waiting List but, instead, chose to model it as an association because that is what it actually represents: that seminar objects maintain a waiting list of zero or more student objects. Attributes and associations are both properties in the UML 2.0 so they're treated as basically the same sort of thing. I also showed associations are implemented as a combination of attributes and operations - I prefer to keep my models simple and assume that the attributes and operations exist to implement the associations. Furthermore that would be a detailed design issue anyway, something that isn't appropriate on a conceptual model.
Figure 2. Initial conceptual class diagram.
The on waiting list association is unidirectional because there isn't yet a need for collaboration in both directions. Follow the AM practice of Create Simple Content and don't over model - you don't need a bi-directional association right now so don't model it. The enrolled in association between the Student and Enrollment classes is also uni-directional for similar reasons. For this association it appears student objects know what enrollment records they are involved with, recording the seminars they have taken in the past, as well as the seminars in which they are currently involved. This association would be traversed to calculate their student object's average mark and to provide information about seminars taken. There is also an enrolled in association between Enrollment and Seminar to support the capability for student objects to produce a list of seminars taken. The instructs association between the Professor class and the Seminar class is bidirectional because professor objects know what seminars they instruct and seminar objects know who instruct them.
When I'm conceptual modeling my style is to name attributes and methods using the formats Attribute Name and Method Name, respectively. Following a consistent and sensible naming convention helps to make your diagrams readable, an important benefit of AM's Apply Modeling Standards practice. Also notice in Figure 2 how I haven't modeled the visibility of the attributes and methods to any great extent. Visibility is an important issue during design but, for now, it can be ignored. Also notice I haven't defined the full method signatures for the classes. This is another task I typically leave to design.
I was able to determine with certainty, based on this information, the multiplicities for all but one association and for that one I marked it with a note so I know to discuss it further with my stakeholders. Notice my use of question marks in the note. My style is to mark unknown information on my diagrams this way to remind myself that I need to look into it.
In Figure 2 I modeled a UML constraint, in this case {ordered FIFO} on the association between Seminar and Student. The basic idea is that students are put on the waiting list on a first-come, first-served/out (FIFO) basis. In other words, the students are put on the waiting list in order. UML constraints are used to model complex and/or important information accurately in your UML diagrams. UML constraints are modeled using the format "{constraint description}" format, where the constraint description may be in any format, including predicate calculus. My preference is to use UML notes with English comments, instead of formal constraints, because they're easier to read.
2. Design Class Diagrams
Coming soon
Figure 3. A design class diagram.
3. How to Create Class Diagrams
To create and evolve a conceptual class diagram, you need to iteratively model:
To create and evolve a design class diagram, you need to iteratively model:
3.1 Classes
An object is any person, place, thing, concept, event, screen, or report applicable to your system. Objects both know things (they have attributes) and they do things (they have methods). A class is a representation of an object and, in many ways, it is simply a template from which objects are created. Classes form the main building blocks of an object-oriented application. Although thousands of students attend the university, you would only model one class, called Student, which would represent the entire collection of students.
3.2 Responsibilities
Classes are typically modeled as rectangles with three sections: the top section for the name of the class, the middle section for the attributes of the class, and the bottom section for the methods of the class. The initial classes of your model can be identified in the same manner as they are when you are CRC modeling, as will the initial responsibilities (its attributes and methods). Attributes are the information stored about an object (or at least information temporarily maintained about an object), while methods are the things an object or class do. For example, students have student numbers, names, addresses, and phone numbers. Those are all examples of the attributes of a student. Students also enroll in courses, drop courses, and request transcripts. Those are all examples of the things a student does, which get implemented (coded) as methods. You should think of methods as the object-oriented equivalent of functions and procedures.
An important consideration the appropriate level of detail. Consider the Student class modeled in Figure 2 which has an attribute called Address. When you stop and think about it, addresses are complicated things. They have complex data, containing street and city information for example, and they potentially have behavior. An arguably better way to model this is depicted in Figure 4. Notice how the Address class has been modeled to include an attribute for each piece of data it comprises and two methods have been added: one to verify it is a valid address and one to output it as a label (perhaps for an envelope). By introducing the Address class, the Student class has become more cohesive. It no longer contains logic (such as validation) that is pertinent to addresses. The Address class could now be reused in other places, such as the Professor class, reducing your overall development costs. Furthermore, if the need arises to support students with several addresses¾during the school term, a student may live in a different location than his permanent mailing address, such as a dorm¾information the system may need to track. Having a separate class to implement addresses should make the addition of this behavior easier to implement.
Figure 4. Student and address (Conceptual class diagram).
An interesting feature of the Student class is its Is Eligible to Enroll responsibility. The underline indicates that this is a class-level responsibility, not an instance-level responsibility (for example Provide Seminars Taken). A good indication that a responsibility belongs at the class level is one that makes sense that it belongs to the class but that doesn't apply to an individual object of that class. In this case this operation implements BR129 Determine Eligibility to Enroll called out in the Enroll in Seminar system use case.
The Seminar class of Figure 2 is refactored into the classes depicted in Figure 5. Refactoring such as this is called class normalization (Ambler 2004), a process in which you refactor the behavior of classes to increase their cohesion and/or to reduce the coupling between classes. A seminar is an offering of a course, for example, there could be five seminar offerings of the course "CSC 148 Introduction to Computer Science." The attributes name and fees where moved to the Course class and courseNumber was introduced. The getFullName() method concatenates the course number, "CSC 148" and the course name "Introduction to Computer Science" to give the full name of the course. This is called a getter method, an operation that returns a data value pertinent to an object. Although getter methods, and the corresponding setter methods, need to be developed for a class they are typically assumed to exist and are therefore not modeled (particularly on conceptual class diagrams) to not clutter your models.
Figure 5. Seminar normalized (Conceptual class diagram).
Figure 6. Course with accessor methods (Inching towards a design class diagram).
3.3 Associations
Objects are often associated with, or related to, other objects. For example, as you see in Figure 2 several associations exist: Students are ON WAITING LIST for seminars, professors INSTRUCT seminars, seminars are an OFFERING OF courses, a professor LIVES AT an address, and so on. Associations are modeled as lines connecting the two classes whose instances (objects) are involved in the relationship.
When you model associations in UML class diagrams, you show them as a thin line connecting two classes, as you see in Figure 6. Associations can become quite complex; consequently, you can depict some things about them on your diagrams. The label, which is optional, although highly recommended, is typically one or two words describing the association. For example, professors instruct seminars.
Figure 6. Notation for associations.
It is not enough simply to know professors instruct seminars. How many seminars do professors instruct? None, one, or several? Furthermore, associations are often two-way streets: not only do professors instruct seminars, but also seminars are instructed by professors. This leads to questions like: how many professors can instruct any given seminar and is it possible to have a seminar with no one instructing it? The implication is you also need to identify the multiplicity of an association. The multiplicity of the association is labeled on either end of the line, one multiplicity indicator for each direction (Table 1 summarizes the potential multiplicity indicators you can use).
Table 1. Multiplicity Indicators.
| Indicator | Meaning |
| 0..1 | Zero or one |
| 1 | One only |
| 0..* | Zero or more |
| 1..* | One or more |
| n | Only n (where n > 1) |
| 0..n | Zero to n (where n > 1) |
| 1..n | One to n (where n > 1) |
Another option for associations is to indicate the direction in which the label should be read. This is depicted using a filled triangle, called a direction indicator, an example of which is shown on the offering of association between the Seminar and Course classes of Figure 5. This symbol indicates the association should be read "a seminar is an offering of a course," instead of "a course is an offering of a seminar." Direction indicators should be used whenever it isn't clear which way a label should be read. My advice, however, is if your label is not clear, then you should consider rewording it.
The arrowheads on the end of the line indicate the directionality of the association. A line with one arrowhead is uni-directional whereas a line with either zero or two arrowheads is bidirectional. Officially you should include both arrowheads for bi-directional assocations, however, common practice is to drop them (as you can see, I prefer to drop them).
At each end of the association, the role, the context an object takes within the association, may also be indicated. My style is to model the role only when the information adds value, for example, knowing the role of the Student class is enrolled student in the enrolled in association doesn't add anything to the model. I follow the AM practice Depict Models Simply and indicate roles when it isn't clear from the association label what the roles are, if there is a recursive association, or if there are several associations between two classes.
3.4 Inheritance Relationships
Similarities often exist between different classes. Very often two or more classes will share the same attributes and/or the same methods. Because you don't want to have to write the same code repeatedly, you want a mechanism that takes advantage of these similarities. Inheritance is that mechanism. Inheritance models "is a" and "is like" relationships, enabling you to reuse existing data and code easily. When A inherits from B, we say A is the subclass of B and B is the superclass of A. Furthermore, we say we have "pure inheritance" when A inherits all the attributes and methods of B. The UML modeling notation for inheritance is a line with a closed arrowhead pointing from the subclass to the superclass.
Many similarities occur between the Student and Professor classes of Figure 2. Not only do they have similar attributes, but they also have similar methods. To take advantage of these similarities, I created a new class called Person and had both Student and Professor inherit from it, as you see in Figure 7. This structure would be called the Person inheritance hierarchy because Person is its root class. The Person class is abstract: objects are not created directly from it, and it captures the similarities between the students and professors. Abstract classes are modeled with their names in italics, as opposed to concrete classes, classes from which objects are instantiated, whose names are in normal text. Both classes had a name, e-mail address, and phone number, so these attributes were moved into Person. The Purchase Parking Pass method is also common between the two classes, something we discovered after Figure 2 was drawn, so that was also moved into the parent class. By introducing this inheritance relationship to the model, I reduced the amount of work to be performed. Instead of implementing these responsibilities twice, they are implemented once, in the Person class, and reused by Student and Professor.
Figure 7. Inheritance hierarchy.
3.5 Composition Associations
Sometimes an object is made up of other objects. For example, an airplane is made up of a fuselage, wings, engines, landing gear, flaps, and so on. Figure 8 presents an example using composition, modeling the fact that a building is composed of one or more rooms, and then, in turn, that a room may be composed of several subrooms (you can have recursive composition). In UML 2, aggregation would be shown with an open diamond.
Figure 8. Modeling composition.
I'm a firm believer in the "part of" sentence rule -- if it makes sense to say that something is part of something else then there's a good chance that composition makes sense. For example it makes sense to say that a room is part of a building, it doesn't make sense to say that an address is part of a person. Another good indication that composition makes sense is when the lifecycle of the part is managed by the whole -- for example a plane manages the activities of an engine. When deciding whether to use composition over association, Craig Larman (2002) says it best: If in doubt, leave it out. Unfortunately many modelers will agonize over when to use composition when the reality is little difference exists among association and composition at the coding level.
3.6 Vocabularies
In Agile Database Techniques (Ambler 2004) I discussed the importance of vocabularies when it comes to modeling XML data structures. A vocabulary defines the semantics of entity types and their responsibilities, the taxonomical relationships between entity types, and the ontological relationships between entity types. Semantics is simply a fancy word for meaning - when we're defining the semantics of something we're defining it's meaning. Taxonomies are classifications of entity types into hierarchies, an example of which is presented for persons Figure 9. Ontology goes beyond taxonomy. Where taxonomy addresses classification hierarchies ontology will represent and communicate knowledge about a topic as well as a set of relationships and properties that hold for the entities included within that topic.
Figure 9. A taxonomy for people within the university.
The semantics of your conceptual model are best captured in a glossary. There are several interesting aspects of Figure 9:
-
It takes a "single section" approach to classes, instead of the three section approach that we've seen in previous diagrams, because we're exploring relationships between entity types but not their responsibilities.
-
It uses UML 2.0's generalization set concept, basically just an inheritance arrowhead with a label representing the name of the set. In UML 1.x this label was called a discriminator. There are three generalization sets for Person: Nationality, Role, and Gender.
-
These generalization sets overlap - a person can be classified via each of these roles (e.g. someone can be a male foreign student). This is called multiple classification.
-
You can indicate "sub generalization" sets, for example Student within the Role generalization set.
-
Some generalization sets are mutually exclusive from others, not shown in the example, where an entity type may only be in one set. This is referred to as single classification and would be modeled using an XOR (exclusive OR) constraint between the two (or more) discriminators.
Source
This artifact description is excerpted from Chapters 8 and 12 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.
Monday, August 25, 2008
Uncovering Requirements With UML Class Diagrams
Saturday, August 23, 2008
Wednesday, August 20, 2008
Saturday, August 16, 2008
Wednesday, August 6, 2008
Volere Requirements Template
Volere
Volere is the result of many years of practice, consulting and research in requirements engineering. We have packaged our experience in the form of a generic requirements process, requirements training, requirements consultancy, requirements audits, a variety of downloadable guides and this requirements template. We also provide requirements specification writing services.
The Volere requirements process is described in the book Mastering the Requirements Process by Suzanne Robertson and James Robertson, Addison-Wesley, London, 1999. ISBN 0-201-36046-2
Volere for managers, team leaders and advanced analysts is covered in the book: Requirements-Led Project Management — Discovering David's Slingshot by Suzanne Robertson and James Robertson, Addison-Wesley, London, 2005. ISBN 0-321-18062-3
Public seminars on Volere are run on a regular basis in Europe, United States and Australia. See the home page for a schedule of courses
In house seminars and consulting on Volere can be arranged on demand. For further information contact:
The Atlantic Systems Guild
11 St Mary's Terrace
London W2 1SU
United Kingdom
email: suzanne@systemsguild.com
email: james@systemsguild.com
| Table of Contents | The Template | |
|
|
For ease of use, we have found it convenient to think of requirements as belonging to a type.
Functional requirements are the fundamental or essential subject matter of the product. They describe what the product has to do or what processing actions it is to take.
Nonfunctional requirements are the properties that the functions must have, such as performance and usability. Do not be deterred by the unfortunate type name (we use it because it is the most common way of referring to these types of requirements). These requirements are as important as the functional requirements for the product's success.
Project constraints are restrictions on the product due to the budget or the time available to build the product.
Design constraints impose restrictions on how the product must be designed. For example, it might have to be implemented in the hand-held device being given to major customers, or it might have to use the existing servers and desktop computers, or any other hardware, software, or business practice.
Project drivers are the business-related forces. For example, the purpose of the project is a project driver, as are all of the stakeholders-each for different reasons.
Project issues define the conditions under which the project will be done. Our reason for including them as part of the requirements is to present a coherent picture of all factors that contribute to the success or failure of the project and to illustrate how managers can use requirements as input when managing a project.
Testing requirements
Start testing requirements as soon as you start writing them.
You make a requirement testable by adding its fit criterion. This fit criterion measures the requirement, making it possible to determine whether a given solution fits the requirement. If a fit criterion cannot be found for a requirement, then the requirement is either ambiguous or poorly understood. All requirements can be measured, and all should carry a fit criterion.
Requirement Shell
Use this requirement shell as a guide for writing each requirement. 
Requirement Numbering
Give each requirement a unique identifier to make it traceable throughoutthe development process. The numbering scheme suggested in the requirementshell is:
Requirement # is the next unique requirement number
Requirement Type is the section number from the template for thistype of requirement
The inclusion of the section number is not absolutely necessary becausewe do have a unique requirement id. However it serves as a reminder of whatthis requirement relates to and helps to remind why the requirement is consideredimportant. Also the ability to compare requirements of the same type makesit easier to identify contradictions and duplications.
For example:
A functional requirement is section 9, and the next unique number is128.
Requirement #: 128 Requirement Type: 9
The product shall record the time when it is notified of a truck breakdown
A performance requirement comes from section 12, and the next uniquenumber is 129.
Requirement #: 129 Requirement Type: 12
The product shall inform the truck drivers of their schedule 30 minutes before they are due to leave the depot.
Event/use case #
is the identifier of a business event or use case that contains thisrequirement. There might be several Event/use case #'s for one requirementbecause the same requirement might relate to a number of events. The termsevent and use case are already widely used in the systems development world.
We use the term business event to mean a business related happening thatcauses an event-response within the work that we are studying.
We use the term event-driven use case (or product use case) to mean auser-defined (or actor defined) piece of activity within the context ofthe product. Business events and product use cases provide a way of groupingbusiness-related requirements and tracing them through into implementation;they are used throughout the Volere development process.
Customer Value
Customer Value is a measure of how much your client cares about eachrequirement.
Ask your stakeholders to grade each requirement for Customer Satisfactionon a scale from 1 to 5 where 1 means mild interest if this requirement issatisfactorily implemented, and 5 means they will be very happy if thisrequirement is satisfactorily implemented
The stakeholders also grade each requirement for Customer Dissatisfactionon a scale from 1 to 5 where 1 means that it hardly matters, and 5 meansthat they will be extremely displeased if this requirement is not satisfactorilyimplemented
The point of having a satisfaction and a dissatisfaction rating is thatit guides your clients to think of the requirement from two different perspectives,and helps you to uncover what they care about most deeply.
Dependencies
This keeps track of other requirements that have an impact on this requirement.
If the dependency exists because requirements use the same information,then use of standard naming conventions and definitions (see Section 5)will implement this dependency.
Other dependencies exist because a solution to this requirement has apositive or negative effect on solutions to other requirements. Capturethese types of dependencies by cross referencing the requirements.
Some requirements, especially project drivers and project constraints,have an impact on all the other requirements.
Conflicts
This keeps track of other requirements that disagree with this one. Conflictsthat are caused by mistake are solved simply by bringing them to the surfaceand resolving them. Other conflicts are because of true differences in opinion/intention.These are the conflicts that might eventually need to be addressed usingnegotiation or mediation techniques. There is nothing wrong with havingconflicting requirements providing you know that you have them. Then youare in a position to address the conflict.
History
We follow the requirement from the date that it was created, throughall its changes. We minimise future confusion by recording the rationalefor making major changes. When a requirement is deleted we record when andthe rationale behind the deletion. The date that the requirement passesits quality checks, and who passed it, is also recorded.
Definitions used inthis template
Context of the Product: The boundaries between the product thatwe intend to build and the people, organisations, other products and piecesof technology that have a direct interface with the product.
Context of the Work: The subject matter, people and organisationsthat might have an impact on the requirements for the product. The contextof study identifies the intersection of all the domains of interest.
Client: The person or organisation for whom the product is beingbuilt, usually responsible for paying for the development of the product.
Customer: The person or organisation who will buy the product(note that the same person/organisation might play both the client, customerand sometimes user roles)
Design or Systems Design: Crafting a solution to fit the requirements.
Developers: The people who specify and build the product.
Domain of Interest: A subject matter area that has some relevanceto the context of study.
Non-Functional Requirement: A property that the eventual productmust have.
Event: We use the term business event to mean a business relatedhappening within a system adjacent to the work that we are studying. Thehappening causes the work to produce an event-response.
Fit Criterion: Objective measure for defining the meaning of arequirement, and eventually testing whether a given solution satisfies theoriginal requirement.
Functional Requirement: An action that the product mustbe able to take, something that the product must do.
Global Constraint: Constraints that apply to the systemas a whole.
Product: This is what we are attempting to deliver. This couldbe a piece of software, the installation of a package, a set of procedures,a piece of hardware, a piece of machinery, a new organization, or almostanything.
Requirement: A measurable statement of intent about somethingthat the product must do, or a property that the product must have, or aconstraint on the system.
Stakeholder: A stakeholder is a person who can affect the outcome/successof the project and/or is affected by its outcome/success.
System: The business system whose requirements are being studied.
Systems Analysis: Detailed study of the requirements, intendedto prove their workability as input to systems design.
Use case: We use the term event-driven use case (or productuse case) to mean a user-defined (or actor defined) piece of activity withinthe context of the product.
User or End User: Someone who has some kind of direct interfacewith the product.
1 The Purpose of the Product
1a. The user problem or background to the project effort.
Content
A short description of the business being done, its context, and the situation that triggered the development effort. It should also describe the work that the user intends to do with the delivered product.
Motivation
Without this statement, the project lacks justification and direction.
Considerations
You should consider whether or not the user problem is serious, and whetherand why it needs to be solved.
1b. Goals of the project.
Content
This boils down to one sentence, or at most a few sentences, that say why we want this product. Here is where you state the real reason the product is being developed.
Motivation
There is a danger that this purpose may get lost along the way. As the development effort heats up, and as the customer and developers discover more about what is possible, the system could potentially wander away from the original goals as it undergoes construction. This is a bad thing unless there is some deliberate act by the client to change the goals. It may be necessary to appoint a person to be custodian of the goals, but it is probably sufficient to make the goals public and periodically remind the developers of them. It should be mandatory to acknowledge the goals at every review session.
Examples
"We want to give immediate and complete response to customers orderingour goods over the telephone."
"We want to be able to forecast the weather."
Measurement
Any reasonable goal must be measurable. This is necessary if you are ever to test whether you have succeeded with the project. The measurement must quantify the advantage gained by the business through doing the project. If the project is worthwhile, there must be some solid business reason for doing it. For example, if the goal of the project is
"We want to give immediate and complete response to customers who order our goods over the telephone."
you have to ask what advantage that goal brings to the organization. If immediate response will result in more satisfied customers, then the measurement must quantify that satisfaction. For example, you could measure the increase in repeat business (on the basis that a happy customer comes back for more), the increase in customer approval ratings from surveys, the increase in revenue from returning customers, and so on.
It is crucial to the rest of the development effort that the goal is firmly established, is reasonable, and is measured. It is usually the latter that makes the former possible.
2. The Client, The Customer and Other Stakeholders
2a. The client.
Content
This item must give the name of the client. It is permissible to haveseveral names, but more than three negates the point.
Motivation
The client has the final say on acceptance of the product, and thus must be satisfied with the product as delivered. You can think of the client as the person who makes the investment in the product. Where the product is being developed for in-house consumption, the roles of the client and the customer are often filled by the same person. If you cannot find a name for your client, then perhaps you should not be building the product.
Considerations
Sometimes, when building a package or a product for external users, the client is the marketing department. In this case, a person from the marketing department must be named as the client.
2b. The customer
Content
The person intended to buy the product. In the case of in-house development, the client and the customer are often the same person. In the case of development of a mass-market product, this section contains a description of the kind of person who is likely to buy the product.
Motivation
The customer is ultimately responsible for deciding whether to buy the product from the client. The correct requirements can be gathered only if you understand the customer and his aspirations when it comes to using your product.
2c. Other stakeholders
Content
The roles and (if possible) names of other people and organizations who are affected by the product, or whose input is needed to build the product.
Examples of stakeholders include:
- Users (detailed in section 3)
- Sponsor
- Testers
- Business Analysts
- Technology Experts
- System Designers
- Marketing Experts
- Legal Experts
- Domain Experts
- Usability Experts
- Representatives of external associations
For a complete checklist, download the stakeholder analysis template from the Volere site.
For each type of stakeholder identify:
- Stakeholder Identification (some combination of role/job title, person name, organisation name),
- Knowledge needed by the project,
- Necessary degree of involvement for that stakeholder/knowledge combination,
- Degree of influence for that stakeholder/knowledge combination,
- Agreement on how to address conflict between stakeholders who have an interest in the same knowledge
Motivation
Failure to recognize stakeholders results in missing requirements.
3. Users of the Product
3a. The hands-on users of the product
Content
A list of the potential users of the product. For each category of user,provide the following information:
User name This is most likely to be the name of a user group like: schoolchildren, road engineers, project managers.
User role Summarizes the users' responsibilities.
Subject matter experience Summarizes the users' knowledge of the business. Rate as novice, journeyman or master.
Technological experience this describes the users' experience with relevant technology. Rate as novice, journeyman or master.
Other user characteristics Describe any characteristics of the users that have an effect on the requirements and eventual design of the product. Describe things like:
- Physical abilities/disabilities
- Intellectual abilities/disabilities
- Attitude to job
- Attitude to technology
- Education
- Linguistic skills
- Age group
- Gender
- Motivation
Motivation
Users are human beings who interface with the product in some way. Use the characteristics of the users to definethe usability requirements for the product. Users are alos known as actors.
Examples
Users can come from wide variety of (sometimes unexpected) sources. Consider the possibility of your users being clerical staff, shop workers, managers, highly trained operators, the general public, casual users, passers-by, illiterate people, tradesmen, students, test engineers, foreigners, children, lawyers, remote users, people using the system over the telephone or an Internet connection, emergency workers, and so on.
3b. The priorities assigned to users
Content
Attach a priority to each category of user. This gives the importance and precedence of the user. Prioritize the users as follows:
Key users: They are critical to the continued success of the product. Give greater importance to requirements generated by this category of user. .
Secondary users: They will use the product, but their opinion of it has no effect on its long-term success. Where there is a conflict between secondary users' requirements and those of key users, the key users take precedence.
Unimportant users: This category of user is given the lowest priority. It includes infrequent, unauthorized, and unskilled users, as well as people who misuse the product.
The percentage of the type of user is intended to assess the amount of consideration given to each category of user.
Motivation
If some users are considered to be more important to the product or to the organization, then this preference should be stated because it should affect the way that you design the product. For instance, you need to know if there is a large customer group who has specifically asked for the product, and for which, if they do not get what they want, the results could be a significant loss of business.
Some users may be listed as having no impact on the product. These users will make use of the product, but have no vested interest in it. In other words, these users will not complain, nor will they contribute. Any special requirements from these users will have a lower design priority.
3c. User participation
Content
Where appropriate, attach to the category of user a statement of the participation that you think will be necessary for those users to provide the requirements. Describe the contribution that you expect these users to provide—for example, business knowledge, interface prototyping, or usability requirements. If possible, assess the minimum amount of time that these users must spend for you to be able to determine the complete requirements.
Motivation
Many projects fail through lack of user participation, sometimes because the required degree of participation was not made clear. When people have to make a choice between getting their everyday work done and working on a new project, the everyday work usually takes priority. This requirement makes it clear, from the outset, that specified user resources must be allocated to the project.
3d. Maintenance Users and Service Technicians
Content
Maintenance users are a special type of hands-on users who have requirements that are specific to maintaining and changing the product.
Motivation
Many of these requirements will be discovered by considering the various types of maintenance requirements detailed in section 14. However, if we define the characteristics of the people who maintain the product, it will help to trigger requirements that might otherwise be missed.
4. Mandated Constraints
This section describes constraints on the eventual design of the product. They are the same as other requirements except that constraints are mandated, usually at the beginning of the project. Constraints have a description, rationale, and fit criterion, and generally are written in the same format as functional and nonfunctional requirements.
4a. Solution Constraints
Content
This specifies constraints on the way that the problem must be solved. Describe the mandated technology or solution. Include any appropriate version numbers. You should also explain the reason for using the technology.
Motivation
To identify constraints that guide the final product. Your client, customer, or user may have design preferences, or only certain solutions may be acceptable. If these constraints are not met, your solution is not acceptable.
Examples
Constraints are written using the same form as other atomic requirements (refer to the requirements shell for the attributes). It is important for each constraint to have a rationale and a fit criterion, as they help to expose false constraints (solutions masquerading as constraints). Also, you will usually find that a constraint affects the entire product rather than one or more product use cases.
- Description: The product shall use the current two-way radio system to communicate with the drivers in their trucks.
- Rationale: The client will not pay for a new radio system, nor are any other means of communication available to the drivers.
- Fit criterion: All signals generated by the product shall be audible and understandable by all drivers via their two-way radio system.
- Description: The product shall operate using Windows XP.
- Rationale: The client uses XP and does not wish to change.
- Fit criterion: The product shall be approved as XP compliant by the MS testing group.
- Description: The product shall be a hand-held device.
- Rationale: The product is to be marketed to hikers and mountain climbers.
- Fit criterion: The product shall weigh no more than 300 grams, no dimension shall be more than 15 centimeters, and there shall be no external power source.
Considerations
We want to define the boundaries within which we can solve the problem. Be careful, because anyone who has experience with or exposure to a piece of technology tends to see requirements in terms of that technology. This tendency leads people to impose solution constraints for the wrong reason, making it very easy for false constraints to creep into a specification. The solution constraints should only be those that are absolutely non-negotiable. In other words, however you solve this problem, you must use this particular technology. Any other solution would be unacceptable.
4b. Implementation Environment of the Current System
Content
This describes the technological and physical environment in which the product is to be installed. It includes automated, mechanical, organizational, and other devices, along with the nonhuman adjacent systems.
Motivation
To describe the technological environment into which the product must fit. The environment places design constraints on the product. This part of the specification provides enough information about the environment for the designers to make the product successfully interact with its surrounding technology.
The operational requirements are derived from this description.
Examples
Examples can be shown as a diagram, with some kind of icon to represent each separate device or person (processor). Draw arrows to identify the interfaces between the processors, and annotate them with their form and content.
Considerations
All the component parts of the current system, regardless of their type,should be included in the description of the implementation environment.
If the product is to affect, or be important to the current organization,include an organization chart.
4c. Partner applications
Content
This describes applications that are not part of the product but withwhich the product will collaborate. These can be external applications,commercial packages or pre-existing in-house applications.
Motivation
To provide information about design constraints that are caused by usingpartner applications. By describing or modeling these partner applications,you discover and highlight potential problems of integration.
Examples
This section can be completed by including written descriptions, models, or references to other specifications. The descriptions must include a full specification of all interfaces that have an effect on the product.
Considerations
Examine the work context model to determine whether any of the adjacent systems should be treated as partner applications. It might also be necessary to examine some of the details of the work to discover relevant partner applications.
4d. Off-the-shelf software
Content
This describes commercial, open source, or any other off-the-shelf software (OTS) that must be used to implement some of the requirements for the product. It could also apply to nonsoftware OTS components such as hardware or any other commercial product that is intended as part of the solution.
Motivation
To identify and describe existing commercial, free, open source, or other products to be incorporated into the eventual product. The characteristics, behavior, and interfaces of the package are design constraints.
Examples
This section can be completed by including written descriptions, modelsor references to supplier's specifications.
Considerations
When gathering requirements, you may discover requirements that conflict with the behavior and characteristics of the OTS software. Keep in mind that the use of OTS software was mandated before the full extent of the requirements became known. In light of your discoveries, you must consider whether the OTS product is a viable choice. If the use of the OTS software is not negotiable, then the conflicting requirements must be discarded.
Note that your strategy for discovering requirements is affected by the decision to use OTS software. In this situation you investigate the work context in parallel with making comparisons with the capabilities of the OTS product. Depending on the comprehensibility of the OTS software, you might be able to discover the matches or mismatches without having to write each of the business requirements in atomic detail. The mismatches are the requirements that you will need to specify so that you can decide whether to satisfy them by either modifying the OTS software or modifying the business requirements.
Given the spate of lawsuits in the software arena, you should consider whether any legal implications might arise from your use of OTS. You can cover this in section 17. Legal Requirements.
4e. Anticipated workplace environment
Content
This describes the workplace in which the users are to work and use the product. It should describe any features of the workplace that could have an effect on the design of the product, and the social and culture of the workplace. .
Motivation
To identify characteristics of the workplace so that the product is designed to compensate for any difficulties.
Examples
- The printer is a considerable distance from the user's desk. This constraint suggests that printed output should be de-emphasized.
- The workplace is noisy, so audible signals might not work.
- The workplace is outside so the product must be waterproof, have displays that are visible in sunlight and allow for the effect of wind on any paper output.
- The product is to be used in a library; it must be extra quiet.
- The product is a photocopier to be used by an environmentally conscious organization; it must work with recycled paper.
- The user will be standing up or working in positions where he must hold the product. This suggests a hand-held product, but only a careful study of the users' work and workplace will provide the necessary input to identifying the operational requirements.
Considerations
The physical work environment constrains the way that work is done. The product should overcome whatever difficulties exist; however, you might consider a redesign of the workplace as an alternative to having the product compensate for it.
4f. Schedule Constraints
Content
Any known deadlines, or windows of opportunity, should be stated here.
Motivation
To identify critical times and dates that have an effect on product requirements.If the deadline is short, then the requirements must be kept to whatevercan be built within the time allowed.
Examples
- To meet scheduled software releases.
- There may be other parts of the business or other software products that are dependent on this product.
- Windows of marketing opportunity.
- Scheduled changes to the business that will use your product. For example the organization may be starting up a new factory and your product is needed before production can commence.
Considerations
State deadline limitations that exist by stating the date and describingwhy it is critical. Also identify prior dates where parts of your productneed to be available for testing.
You should also ask questions about the impact of not meeting the deadlinelike:
- What happens if we don't build the product by the end of the calendar year?
- What is the financial impact of not having the product by the beginning of the Christmas buying season?
4g. Budget Constraints
Content
The budget for the system, expressed in money or available resources.
Motivation
The requirements must not exceed the budget. This may constrain the numberof requirements that can be included in the product.
The intention of this question is to determine if the product is reallywanted.
Considerations
Is it realistic to build a product within this budget? If the answerto this question is no, then either the client is not really committed tobuilding the product or does not place enough value on the product. In eithercase you should consider whether it is worthwhile continuing.
5. Naming Conventions and Definitions
5a. Definitions of All Terms, Including Acronyms, Used in the Project.
Content
A glossary containing the meanings of all names, acronyms, and abbreviations used within the requirements specification. Select names carefully to avoid giving a different, unintended meaning.
This glossary reflects the terminology in current use within the work area. You might also build on the standard names used within your industry.
For each term, write a succinct definition. The appropriate stakeholders must agree on this definition.
Avoid abbreviations, as they introduce ambiguity, require additional translations, and could potentially lead to misinterpretation in the mind of anyone who is trying to understand your requirements. Ask your requirements analysts to replace all abbreviations with the correct term. This is easily done with word processors.
Acronyms are acceptable if they are completely explained by a definition.
Motivation
Names are very important. They invoke meanings that, if carefully defined,can save hours of explanations. Attention to names at this stage of theproject helps to highlight misunderstandings.
The glossary produced during requirements is used and extended throughout the project.
Examples
Truck: A vehicle used for spreading de-icing material on roads. ÒTruckÓ is not used to refer to goods-carrying vehicles.
BIS: Business Intelligence Service. The department run by Steven Peters to supply business intelligence for the rest of the organization
Considerations
Make use of existing references and data dictionaries. Obviously, it is best to avoid renaming existing items unless they are so ambiguous that they cause confusion.
From the beginning of the project, emphasize the need to avoid homonyms and synonyms. Explain how they increase the cost of the project.
5b. Data Dictionary for Any Included Models
Content
Dictionary definitions of all information flows and stores used in models. Particular consideration should be given to defining the data attributes of all flows shown the context models (see sections 7 and 8).
This section should also contain any technical specifications for interfaces shown on the context models.
Motivation
The context diagram provides an accurate definition of the scope of the work being studied or the scope of the product to be built. This definition can be completely accurate only if the information flows bordering the scope have their attributes defined.
Examples
Road de-icing schedule = issue number + {road section identifier + treatment start time + critical start time + truck identifier} + depot identifier
As you progress through the requirements specification, define each of the elementary terms in detail.
Considerations
The dictionary provides a link between the requirements analysts and the implementers. The implementers add implementation details to the terms in the dictionary, defining how the data will be implemented. Also, implementers add terms that are present because of the chosen technology and that are independent of the business requirements.
6. Relevant Facts and Assumptions
6a.Facts
Content
Factors that have an effect on the product, but are not mandated requirements constraints. They could be business rules, organizational systems, or any other activities that have an effect on this product. Facts are things you want the reader of the specification to know. .
Motivation
Relevant facts provide background information to the specification readers, and might contribute to requirements. They will have an effect on the eventual design of the product.
Examples
One ton of de-icing material will treat three miles of single-lane roadway.
The existing application is 10,000 lines of C code.
6b. Assumptions
Content
A list of the assumptions that the developers are making. These assumptions might be about the intended operational environment, but can be about anything that has an effect on the product. As part of managing expectations, assumptions also contain statements about what the product will not do.
Motivation
To make people declare the assumptions that they are making. Also, to make everyone on the project aware of assumptions that have already been made.
Examples
Assumptions about new laws or political decisions.
Assumptions about what your developers expect to be ready in time for them to use. For example, other parts of your products, the completion of other projects, software tools, software components, etc.
Assumptions about the technological environment in which the product will operate. These assumptions should highlight areas of expected compatibility.
The software components that will be available to the developers.
Other products being developed at the same time as this one.
Availability and capability of bought-in components.
Dependencies on computer systems or people external to this project
The requirements that will specifically not be carried out by the product.
Considerations
We often make unconscious assumptions. It is necessary to talk to the members of the project team to discover any unconscious assumptions that they have made. Ask stakeholders (both technical and business-related) questions such as these:
- What software tools are you expecting to be available?
- Will there be any new software products?
- Are you expecting to use a current product in a new way?
- Are there any business changes you are assuming we will be able to deal with?
It is important to state these assumptions up front. You might also consider the probability of whether the assumption is correct and, where relevant, a list of alternatives if something that is assumed does not happen.
The assumptions are intended to be transient. That is, they should all be cleared by the time the specification is released-the assumption should have become either a requirement or a constraint. For example, if the assumption related to the capability of a product that is intended to be a partner product to yours, then the capability should have been proven satisfactory, and it becomes a constraint to use it. Conversely, if the bought-in product is not suitable, then it becomes a requirement for the project team to construct the needed capability.
7. The Scope of the Work
7a. The Current Situation
Content
This is an analysis of the existing business processes, including the manual and automated processes that might be replaced or changed by the new product. Business analysts might already have done this investigation as part of the business case analysis for the project.
Motivation
If your project intends to make changes to an existing manual or automated system, you need to understand the effect of proposed changes. The study of the current situation provides the basis for understanding the effects of proposed changes and choosing the best alternatives.7b. The Context of the Work.
Content
The work context diagram identifies the work that we need to investigatein order to be able to build the product. Note that this includes more thanthe intended product. Unless we understand the work that the product willsupport, there is little chance of building a product that will fit cleanlyinto its environment.
The adjacent systems on the context diagram shown below (e.g., Weather Forecasting Service) indicate other subject matter domains (systems, people, and organizations) that need to be understood. The interfaces between the adjacent systems and the work context indicate why we are interested in the adjacent system. In the case of Weather Forecasting Service, we can say that we are interested in the details of when, how, where, who, what, and why it produces the District Weather Forecasts information.
Motivation
To clearly define the boundaries for the work study and requirementseffort. Without this definition, there is little chance of building a productthat will fit seamlessly into its environment.
Examples
Considerations
The names used on the context diagram should be consistent with the naming conventions and data dictionary definitions presented in section 5. Without these definitions, the context model lacks the required rigor, and it may be misunderstood. Relevant stakeholders must agree to the definitions of the interfaces shown on the context model.
7c. Work partitioning
Content
A list showing all business events to which the work responds. Business events are happenings in the real world that affect the work. They also happen because it is time for the work to do something-for example, produce weekly reports, remind nonpaying customers, check the status of a device, and so on. The response to each event is called a business use case; it represents a discrete partition of work that contributes to the total functionality of the work.
The event list includes:
- Business event Name
- Input from adjacent systems (identical with name on context diagram)
- Output to adjacent systems (identical with name on context diagram)
- Brief summary of the business use case (This is optional, but we have found it is a very useful first step in defining the requirements for the business use case—you can think of it as a mini-scenario.)
Motivation
To identify logical chunks of the system that can be used as the basis for discovering detailed requirements. These business events also provide the subsystems that can be used as the basis for managing detailed analysis and design.
Example
Business Event List
| Event Name | Input & Output | Summary |
| 1. Weather Station transmits reading | Weather Station Readings (in) | Record the readings as belonging to the weather station. |
| 2. Weather Service forecasts weather | District Weather Forecast (in) | Record the forecast. |
| 3. Road engineers advise changed roads | Changed Road (in) | Record the new or changed road. Check that all appropriate weather stations are attached. |
| 4. Road Engineering installs new weather station | New Weather Station (in) | Record the weather station and attach it to the appropriate roads. |
| 5. Road Engineering changes weather station | Changed Weather Station (in) | Record the changes to the weather station. |
| 6. Time to test Weather Stations | Failed Weather Station Alert (out) | Determine if any weather stations have not transmitted for two hours, and inform Road Engineering of any failures. |
| 7. Truck Depot changes a truck | Truck Change (in) | Record the changes to the truck. |
| 8. Time to detect icy roads | Road De-icing Schedule (out) | Predict the ice situation for the next two hours. Assign a truck to any roads that will freeze. Issue the schedule. |
| 9. Truck treats a road | Treated Road (in) | Record the road as being in a safe condition for the next three hours. |
| 10 Truck Depot reports problem with truck |
| Reassign available trucks to the previously assigned roads. |
| 11. Time to monitor road treatment | Untreated Road Reminder (out) | Check that all scheduled roads have been treated in the assigned time, and issue reminders for any untreated roads. |
Considerations
Attempting to list the business events is a way of testing the work context. This activity uncovers uncertainties and misunderstandings about the project and facilitates precise communications. When you do an event analysis, it will usually prompt you to make some changes to your work context diagram.
We suggest you gather requirements for discrete sections of the work. This requires you to partition the work, and we have found business events to be the most convenient, consistent, and natural way to break the work into manageable units.
8. The Scope of the Product
8a Product Boundary
A use case diagram identifies the boundaries between the users (actors) and the product. You arrive at the product boundary by inspecting each business use case and determining, in conjunction with the appropriate stakeholders, which part of the business use case should be automated (or satisfied by some sort of product) and what part should be done by the user. This task must take into account the abilities of the actors (section 3), the constraints (section 4), the goals of the project (section 1), and your knowledge of both the work and the technology that can make the best contribution to the work.
The use case diagram (see below) shows the actors outside the product boundary (the rectangle). The product use cases are the ellipses inside the boundary. The lines denote usage. Note that actors can be either automated or human.
Derive the product use cases by deciding where the product boundary should be for each business use case. These decisions are based on your knowledge of the work and the requirements constraints.
8b Product Use Case List
The use case diagram is a graphical way of summarizing the product use cases relevant to the product. If you have a large number of product use cases (we find 15-20 is a good limit), then it is better to make a list of the product use cases and model or describe each one individually.
8c. Individual Product Use Cases
This is where you keep details about the individual product use cases on your list. You can include a scenario for each product use case on your list.
9. Functional and Data Requirements
9a. Functional Requirements.
Content
A specification for each individual functional requirement. As with alltypes of requirements, use the Requirements Shell. A full explanationis included in this template's introductory material.
Motivation
To specify the detailed functional requirements for the activity of the product.
Example
Fit Criterion
Each functional requirement should have a fit criterion or a test case. In any event, the fit criterion is the benchmark to allow the tester to determine whether the implemented product has met the requirement.
Considerations
If you have produced an event/use case list (see sections 7b and 8a), then you can use it to help you trigger the functional requirements for each event/use case. If you have not produced an event/use case list, give each functional requirement a unique number and, to help with traceability, partition these requirements into event/use case-related groups later in the development process.
9b. Data requirements.
Content
A specification of the essential subject matter, business objects, entities, and classes that are germane to the product. It might take the form of a first-cut class model, an object model, or a domain model. Alternatively, these requirements might be described by defining the terms in the dictionary described in section 5.
Motivation
To clarify the system's subject matter, thereby triggering recognition of requirements not yet considered.
Example
The following is a model of the system's business subject matter usingthe Unified Modelling Language (UML) class model notation.
You can use any type of data or object model to capture this knowledge. The issue is to capture the meaning of the business subject matter and the connections between the individual parts, and to show that you are consistent within your project. If you have an established company standard notation, use that, as it will help you to reuse knowledge between projects.
Considerations
Are there any data or object models for similar or overlapping systems that might be a useful starting point? Is there a domain model for the subject matter dealt with by this system?
10. Look and Feel Requirements
10a. Appearance Requirements
Content
The section contains requirements relating to the spirit of the product. Your client may have made particular demands for the product, such as corporate branding, colors to be used, and so on. This section captures the requirements for the appearance. Do not attempt to design it until the appearance requirements are known.
Motivation
To ensure that the appearance of the product conforms to the organizationÕs expectations.
Examples
The product shall be attractive to a teenage audience.
The product shall comply with corporate branding standards.
Fit Criterion
A sampling of representative teenagers shall, without prompting or enticement, start using the product within four minutes of their first encounter with it.
The office of branding shall certify the product complies with the current standards.
Considerations
Even if you are using prototypes, it is important to understand the requirements for the appearance. The prototype is used to help elicit requirements; it should not be thought of as a substitute for the requirements.
10b. Style Requirements
Content
Requirements that specify the mood, style, or feeling of the product, which influences the way a potential customer will see the product. Also, the stakeholders' intentions for the amount of interaction the user is to have with the product.
In this section, you would also describe the appearance of the package if this is to be a manufactured product. The package may have some requirements as to its size, style, and consistency with other packages put out by your organization. Keep in mind the European laws on packaging, which require that the package not be significantly larger than the product it encloses.
The style requirements that you record here will guide the designers to create a product as envisioned by your client.
Motivation
Given the state of today's market and people's expectations, we cannot afford to build products that have the wrong style. Once the functional requirements are satisfied, it is often the appearance and style of products that determine whether they are successful. Your task in this section is to determine precisely how the product shall appear to its intended consumer.
Example
The product shall appear authoritative.
Fit Criterion
After their first encounter with the product, 70 percent of representative potential customers shall agree they feel they can trust the product.
Considerations
The look and feel requirements specify your client's vision of the product's appearance. The requirements may at first seem to be rather vague (e.g., "conservative and professional appearance"), but these will be quantified by their fit criteria. The fit criteria give you the opportunity to extract from your client precisely what is meant, and give the designer precise instructions on what he is to accomplish.
11. Usability and Humanity Requirements
This section is concerned with requirements that make the product usable and ergonomically acceptable to its hands-on users.
11a. Ease of use.
Content
This section describes your client's aspirations for how easy it is for the intended users of the product to operate it. The product's usability is derived from the abilities of the expected users of the product and the complexity of its functionality.
The usability requirements should cover properties such as these:
- Efficiency of use: How quickly or accurately the user can use the product.
- Ease of remembering: How much the casual user is expected to remember about using the product.
- Error rates: For some products it is crucial that the user commits very few, or no, errors.
- Overall satisfaction in using the product: This is especially important for commercial, interactive products that face a lot of competition. Web sites are a good example.
- Feedback: How much feedback the user needs to feel confident that the product is actually accurately doing what the user expects. The necessary degree of feedback will be higher for some products (e.g., safety-critical products) than for others.
Motivation
To guide the product's designers toward building a product that meets the expectations of its eventual users.
Examples
The product shall be easy for 11-year-old children to use.
The product shall help the user to avoid making mistakes.
The product shall make the users want to use it.
The product shall be used by people with no training, and possibly no understanding of English.
Fit Criterion
These examples may seem simplistic, but they do express the intention of the client. To completely specify what is meant by the requirement, you must add a measurement against which it can be tested-that is, a fit criterion. Here are the fit criteria for the preceding examples:
Eighty percent of a test panel of 11-year-old children shall be able to successfully complete [list of tasks] within [specified time].
One month's use of the product shall result in a total error rate of less than 1 percent.
An anonymous survey shall show that 75 percent of the intended users are regularly using the product after a three-week familiarization period.
Considerations
Refer to section 3, Users of the Product, to ensure that you have considered the usability requirements from the perspective of all the different types of users.
It may be necessary to have special consulting sessions with your users and your client to determine whether any special usability considerations must be built into the product.
You could also consider consulting a usability laboratory experienced in testing the usability of products that have a project situation (sections 1-7 of this template) similar to yours.
11b. Personalization and Internationalization Requirements
Content
This section describes the way in which the product can be altered or configured to take into account the user's personal preferences or choice of language.
The personalization requirements should cover issues such as the following:
- Languages, spelling preferences, language idioms
- Currencies including the symbols and decimal conventions
- Personal configuration options
Motivation
To ensure that the product's users do not have to struggle with, or meekly accept, the builder's cultural conventions.
Examples
The product shall retain the buyer's buying preferences.
The product shall allow the user to select a chosen language.
Considerations
Consider the country and culture of the potential customers and users of your product. Any out-of-country users will welcome the opportunity to convert to their home spelling and expressions.
By allowing users to customize the way in which they use the product, you give them the opportunity to participate more closely with your organization as well as enjoy their own personal user experience.
You might also consider the configurability of the product. Configurability allows different users to have different functional variations of the product.
11c. Learning Requirements
Content
Requirements specifying how easy it should be to learn to use the product. This learning curve ranges from zero time for products intended for placement in the public domain (e.g., a parking meter or a web site) to a considerable amount of time for complex, highly technical products. (We know of one product where it was necessary for graduate engineers to spend 18 months in a training program before being qualified to use the product.)
Motivation
To quantify the amount of time that your client feels is allowable before a user can successfully use the product. This requirement guides designers to understand how users will learn the product. For example, designers may build elaborate interactive help facilities into the product, or the product may be packaged with a tutorial. Alternatively, the product may have to be constructed so that all of its functionality is apparent upon first encountering it.
Examples
The product shall be easy for an engineer to learn.
A clerk shall be able to be productive within a short time.
The product shall be able to be used by members of the public who will receive no training before using it.
The product shall be used by engineers who will attend five weeks of training before using the product.
Fit Criterion
Fit criterion for the above example requirements are:
An engineer shall produce a [specified result] within [specified time] of beginning to use the product, without needing to use the manual.
After receiving [number of hours] training a clerk shall be able to produce [quantity of specified outputs] per [unit of time].
[Agreed percentage] of a test panel shall successfully complete [specified task] within [specified time limit].
The engineers shall achieve [agreed percentage] pass rate from the final examination of the training.
Considerations
Refer to section 3, Users of the Product, to ensure that you have considered the ease of learning requirements from the perspective of all the different types of users.
11d. Understandability and Politeness Requirements
This section is concerned with discovering requirements related to concepts and metaphors that are familiar to the intended end users.
Content
This specifies the requirement for the product to be understood by its users. While "usability" refers to ease of use, efficiency, and similar characteristics, "understandability" determines whether the users instinctively know what the product will do for them and how it fits into their view of the world. You can think of understandability as the product being polite to its users and not expecting them to know or learn things that have nothing to do with their business problem.
Motivation
To avoid forcing users to learn terms and concepts that are part of the product's internal construction and are not relevant to the users' world. To make the product more comprehensible and thus more likely to be adopted by its intended users.
Examples
The product shall use symbols and words that are naturally understandable by the user community.
The product shall hide the details of its construction from the user.
ConsiderationsRefer to section 3, Users of the Product, and consider the world from the point of view of each of the different types of users.
11e. Accessibility requirements.
Content
The requirements for how easy it should be for people with common disabilities to access the product. These disabilities might be related to physical disability or visual, hearing, cognitive, or other abilities.
Motivation
In many countries it is required that some products be made available to the disabled. In any event, it is self-defeating to exclude this sizable community of potential customers.
Examples
The product shall be usable by partially-sighted users.
The product shall conform to the Americans with Disabilities Act.
Considerations
Some users have disabilities other than the commonly described ones. In addition, some partial disabilities are fairly common. A simple, and not very consequential, example is that approximately 20 percent of males are red-green colorblind.
12. Performance Requirements
12a. Speed and latency requirements
Content
Specifies the amount of time available to complete specified tasks. These requirements often refer to response times. They can also refer to the product's ability to operate at a speed suitable for the intended environment.
Motivation
Some products—usually real-time products—must be able to perform some of their functionality within a given time slot. Failure to do so may mean catastrophic failure (e.g., a ground-sensing radar in an airplane fails to detect an upcoming mountain) or the product will not cope with the required volume of use (e.g., an automated ticket-selling machine).
Examples
Any interface between a user and the automated system shall have a maximum response time of 2 seconds
The response shall be fast enough to avoid interrupting the user's flow of thought
The product shall poll the sensor every 10 seconds
The product shall download the new status parameters within 5 minutes of a change
Fit Criterion
Fit criteria are needed when the description of the requirement is not quantified. However, we find that most performance requirements are stated in quantified terms. The exception is the second requirement shown above, for which the suggested fit criterion is
The product shall respond in less than 1 second for 90 percent of the interrogations. No response shall take longer than 2.5 seconds.
Considerations
There is a wide variation in the importance of different types of speed requirements. If you are working on a missile guidance system, then speed is extremely important. By contrast, an inventory control report that is run once every six months has very little need for a lightning-fast response time.
Customize this section of the template to give examples of the speedrequirements that are important within your environment.
12b. Safety critical requirements
Content
Quantification of the perceived risk of damage to people, property, and environment. Different countries have different standards, so the fit criteria must specify precisely which standards the product must meet.
Motivation
To understand and highlight the damage that could potentially occur when using the product within the expected operational environment.
Examples
The product shall not emit noxious gases that damage people's health.
The heat exchanger shall be shielded from human contact.
Fit Criterion
The product shall be certified to comply with the Health Department's standard E110-98. It is to be certified by qualified testing engineers.
No member of a test panel of [specified size] shall be able to touch the heat exchanger. The heat exchanger must also comply with safety standard [specify which one].
Considerations
The example requirements given here apply to some, but not all, products. It is not possible to give examples of every variation of safety-critical requirement. To make the template work in your environment, you should customize it by adding examples that are specific to your products.
Also, be aware that different countries have different safety standards and laws relating to safety. If you plan to sell your product internationally, you must be aware of these laws. A colleague has suggested that for electrical products, if you follow the German standards, the largest number of countries will be supported.
If you are building safety-critical systems, then the relevant safety-critical standards are already well specified. You will likely have safety experts on your staff. These experts are the best source of the relevant safety-critical requirements for your type of product. They will almost certainly have copious information that you can use.
Consult your legal department. Members of this department will be aware of the kinds of lawsuits that have resulted from product safety failure. This is probably the best starting place for generating relevant safety requirements.
12c. Precision or Accuracy Requirements
Content
Quantification of the desired accuracy of the results produced by the product..
Motivation
To set the client's and users' expectations for the precision of the product.
Examples
All monetary amounts shall be accurate to 2 decimal places.
Accuracy of road temperature readings shall be within + or - 2 degrees Celcius.
Considerations
If you have done any detailed work on definitions, then some precisionrequirements might be adequately defined by definitions in section 5.
You might consider which units the product is intended to use. Readers will recall the spacecraft that crashed on Mars when coordinates were sent as metric data rather than imperial data.
The product might also need to keep accurate time, be synchronized with a time server, or work in UTC.
Also, be aware that some currencies have no decimal places, such as the Japanese yen.
12d. Reliability and Availability requirements
Content
This section quantifies the necessary reliability of the product. The reliability is usually expressed as the allowable time between failures, or the total allowable failure rate.
It also quantifies the expected availability of the product.
Motivation
It is critical for some products not to fail too often. This section allows you to explore the possibility of failure and to specify realistic levels of service. It also gives you the opportunity to set the client's and users' expectations about the amount of time that the product will be available for use.
Examples
The product shall be available for use 24 hours per day, 365 days per year.
The product shall be available for use between the hours of 8:00am and 5:30pm.
The escalator shall run from 6 A.M. until 10 P.M. or the last flight arrives.
The product shall achieve 99% up time.
Considerations
Consider carefully whether the real requirement for your product is that it is available for use or that it does not fail at any time.
Consider also the cost of reliability and availability, and whether itis justified for your product.
12e. Robustness or Fault-Tolerance Requirements
Content
Robustness specifies the ability of the product to continue to function under abnormal circumstances.
Motivation
To ensure that the product is able to provide some or all of its services after or during some abnormal happening in its environment.
Examples
The product shall continue to operate in local mode whenever it loses its link to the central server.
The product shall provide 10 minutes of emergency operation should it become disconnected from the electricity source.
Considerations
Abnormal happenings can almost be considered normal. Today's products are so large and complex that there is a good chance that at any given time, one component will not be functioning correctly. Robustness requirements are intended to prevent total failure of the product.
You could also consider disaster recovery in this section. This plan describes the ability of the product to reestablish acceptable performance after faults or abnormal happenings.
12f. Capacity requirements
Content
This section specifies the volumes that the product must be able to deal with and the amount of data stored by the product.
Motivation
To ensure that the product is capable of processing the expected volumes.
Examples
The product shall cater for 300 simultaneous users within the period from 9:00 A.M. to 11:00 A.M. Maximum loading at other periods will be 150 simultaneous users.
During a launch period, the product shall cater for a maximum of 20 people to be in the inner chamber.
Fit Criterion
In this case, the requirement description is quantified, and thus canbe tested.
12g. Scalability or Extensibility Requirements
Content
This specifies the expected increases in size that the product must be able to handle. As a business grows (or is expected to grow), our software products must increase their capacities to cope with the new volumes.
Motivation
To ensure that the designers allow for future capacities.
Examples
The product shall be capable of processing the existing 100,000 customers. This number is expected to grow to 500,000 within three years.
The product shall be able to process 50,000 transactions per hour within two years of its launch.
13 Operational Requirements
13a. Expected Physical Environment
Content
This section specifies the physical environment in which the productwill operate.
Motivation
To highlight conditions that might need special requirements, preparations, or training. These requirements ensure that the product is fit to be used in its intended environment.
Examples
The product shall be used by a worker, standing up, outside in cold, rainy conditions.
The product shall be used in noisy conditions with a lot of dust.
The product shall be able to fit in a pocket or purse.
The product shall be usable in dim light.
The product shall not be louder than the existing noise level in the environment.
Considerations
The work environment: Is the product to operate in some unusual environment? Does this lead to special requirements? Also see section 11, Usability and Humanity Requirements.
13b. Requirements for Interfacing with Adjacent Systems
Content
This section describes the requirements to interface with partner applications and/or devices that the product needs to successfully operate.
Motivation
Requirements for the interfaces to other applications often remain undiscovered until implementation time. Avoid a high degree of rework by discovering these requirements early.
Examples
The products shall work on the last four releases of the five most popular browsers.
The new version of the spreadsheet must be able to access data from the previous two versions.
Our product must interface with the applications that run on the remote weather stations.
Fit Criterion
For each inter-application interface, specify the following elements:
- The data content
- The physical material content
- The medium that carries the interface
- The frequency
- The volume
13c. Productization Requirements
Content
Any requirements that are necessary to make the product into a distributable or saleable item. It is also appropriate to describe here the operations to be performed to have a software product successfully installed.
Motivation
To ensure that if work must be done to get the product out the door, then that work becomes part of the requirements. Also, to quantify the client's and users' expectations about the amount of time, money, and resources they will need to allocate to install the product.
Examples
The product shall be distributed as a ZIP file.
The product shall be able to be installed by an untrained user without recourse to separately-printed instructions.
The product shall be of a size that it can fit onto one CD.
Considerations
Some products have special needs to turn them into a salable or usable product. You might consider that the product has to be protected such that only paid-up customers can access it.
Ask questions of your marketing department to discover unstated assumptions that have been made about the specified environment and the customers' expectations of how long installation will take and how much it will cost.
Most commercial products have some needs in this area.
13d. Release Requirements
Content
Specification of the intended release cycle for the product and the form that the release shall take.
Motivation
To make everyone aware of how often you intend to produce new releases of the product.
Examples
The maintenance releases will be offered to end users once a year.
Each release shall not cause previous features to fail.
Fit Criterion
Description of the type of maintenance plus the amount of effort budgeted for it.
Considerations
Do you have any existing contractual commitments or maintenance agreements that might be affected by the new product?
14 Maintainability and Support Requirements
14a. Maintenance Requirements
Content
A quantification of the time necessary to make specified changes to theproduct.
Motivation
To make everyone aware of the maintenance needs of the product.
Examples
New MIS reports must be available within one working week of the date when the requirements are agreed upon.
A new weather station must be able to be added to the system overnight
Considerations
There may be special requirements for maintainability, such as that the product must be able to be maintained by its end users or by developers who are not the original developers. These requirements have an effect on the way that the product is developed. In addition, there may be requirements for documentation or training.
You might also consider writing testability requirements in this section.
14b. Supportability Requirements
Content
This specifies the level of support that the product requires. Support is often provided via a help desk. If people will provide support for the product, that service is considered part of the product: Are there any requirements for that support? You might also build support into the product itself, in which case this section is the place to write those requirements.
Motivation
To ensure that the support aspect of the product is adequately specified.
Considerations
Consider the anticipated level of support, and what forms it might take. For example, a constraint might state that there is to be no printed manual. Alternatively, the product might need to be entirely self-supporting.
14c. Adaptability Requirements
Content
Description of other platforms or environments to which the product mustbe ported.
Motivation
To quantify the client's and users' expectations about the platforms on which the product will be able to run.
Examples
The product is expected to run under Windows XP and Linux
The product might eventually be sold in the Japanese market
The product is designed to run in offices, but we intend to have a version which will run in restaurant kitchens
Fit Criterion
Specification of system software on which the product must operate.
Specification of future environments in which the product is expectedto operate.
Time allowed to make the transition.
Considerations
Question your marketing department to discover unstated assumptions that have been made about the portability of the product.
15 Security Requirements
15a. Access requirements
Content
Specification of who has authorized access to the product (both functionality and data), under what circumstances that access is granted, and to which parts of the product access is allowed.
Motivation
To understand the expectations for confidentiality aspects of the system.
Examples
Only direct managers can see the personnel records of their staff.
Only holders of current security clearance can enter the building.
Fit Criterion
System function name or system data name
User role/s and/or names of people who have clearance
Considerations
Is there any data that is sensitive to the management? Is there any data that low-level users do not want management to have access to? Are there any processes that might cause damage or might be used for personal gain? Are there any people who should not have access to the system?
Avoid solving how you will design a solution to the security requirements.For instance, don't design a password system. Your aim here is to identify the security requirement—the design will come from this description.
Consider asking for help. Computer security is a highly-specialised field,and one where improperly-qualified people have no business being. If yourproduct has need of more than average security, we advise that you makeuse of a security consultant. They are not cheap, but the results of inadequatesecurity can be even more expensive.
15b. Integrity requirements
Content
Specification of the required integrity of databases and other files, and of the product itself.
Motivation
To understand the expectations for the integrity of the product's data. To specify what the product will do to ensure its integrity in the case of an unwanted happening such as attack from the outside or unintentional misuse by an authorized user.
Examples
The product shall prevent incorrect data from being introduced.
The product shall protect itself from intentional abuse.
Considerations
Organizations are relying more and more on their stored data. If this data should be come corrupt or incorrect-or disappear-then it could be a fatal blow to the organization. For example, almost half of small businesses go bankrupt after a fire destroys their computer systems. Integrity requirements are aimed at preventing complete loss, as well as corruption, of data and processes.
15c. Privacy requirements
Content
Specification of what the product has to do to ensure the privacy of individuals about whom it stores information. The product must also ensure that all laws related to privacy of an individual's data are observed.
Motivation
To ensure that the product complies with the law, and to protect the individual privacy of your customers. Few people today look kindly on organizations that do not observe their privacy.
Examples
The product shall make its user aware of its information practices before collection data from them.
The product shall notify customers of changes to its information policy.
The product shall reveal private information only in compliance with the organization's information policy.
The product shall protect private information in accordance with relevant privacy laws / the organization's information policy.
Considerations
Privacy issues may well have legal implications, and you are advised to consult with your organization's legal department about the requirements to be written in this section.
Consider what notices you must issue to your customers before collecting their personal information. A notice might go so far as to warn customers that you intend to put a cookie in their computer. Also, do you have to do anything to keep customers aware that you hold their personal information?
Customers must always be in a position to give or withhold consent when their private data is collected or stored. Similarly, customers should be able to view any private data and, where appropriate, ask for correction of the data.
Also consider the integrity and security of private data—for example, when you are storing credit card information.
15d. Audit requirements
Content
Specification of what the product has to do (usually retain records) to permit the required audit checks.
Motivation
To build a system that complies with the appropriate audit rules.
Considerations
This section may have legal implications. You are advised to seek the approval of your organization's auditors regarding what you write here.
You should also consider whether the product should retain information on who has used it. The intention is to provide security such that a user may not later deny having used the product or participated in some form of transaction using the product.
15e. Immunity requirements
Content
The requirements for what the product has to do to protect itself from infection by unauthorized or undesirable software programs, such as viruses, worms, and Trojan horses, among others.
Motivation
To build a product that is as secure as possible from malicious interference.
Considerations
Each day brings more malevolence from the unknown, outside world. People buying software, or any other kind of product, expect that it can protect itself from outside interference.
16 Cultural and Political Requirements
16a. Cultural Requirements
Content
This section contains requirements that are specific to the sociological factors that affect the acceptability of the product. If you are developing a product for foreign markets, then these requirements are particularly relevant.
Motivation
To bring out in the open requirements that are difficult to discover because they are outside the cultural experience of the developers.
Examples
The product shall not be offensive to religious and ethnic groups.
The product shall be able to distinguish between French, Italian and British road numbering systems.
The product shall keep a record of public holidays for all countries in the European Union and for all states in the United States.
Considerations
Question whether the product is intended for a culture other than the one with which you are familiar. Ask whether people in other countries or in other types of organizations will use the product. Do these people have different habits, holidays, superstitions, or cultural norms that do not apply to your own culture? Are there colors, icons, or words that have different meanings in another cultural environment?
16b. Political Requirements
Content
This section contains requirements that are specific to the political factors that affect the acceptability of the product.
Motivation
To understand requirements that sometimes appear irrational.
Examples
The product shall be installed using only American-made components.
The product shall make all functionality available to the CEO.
Considerations
Did you intend to develop the product on a Macintosh, when the office manager has laid down an edict that only Windows machines are permitted?
Is a director also on the board of a company that manufactures products similar to the one that you intend to build?
Whether you agree with these political requirements has little bearing on the outcome. The reality is that the system has to comply with political requirements even if you can find a better, more efficient, or more economical solution. A few probing questions here may save some heartache later.
The political requirements might be purely concerned with the politics inside your organization. However, in other situations you may need to consider the politics inside your customers' organizations or the national politics of the country.
17 Legal Requirements
17a. Compliance Requirements
Content
A statement specifying the legal requirements for this product.
Motivation
To comply with the law so as to avoid later delays, law suits and legalfees.
Examples
Personal information shall be implemented so as to comply with the data protection act.
Fit Criterion
Lawyers' opinion that the product does not break any laws.
Considerations
Consider consulting lawyers to help identify the legal requirements
The Sarbanes-Oxley (SOX) Act, the Health Insurance Portability and Accountability Act (HIPAA) and the Gramm-Leach-Bliley Act may have implications for you. Check with your company lawyer.
Are there any copyrights or other intellectual property that must be protected? Conversely, do any competitors have copyrights on which you might be in danger of infringing?
Is it a requirement that developers have not seen competitors' code oreven have worked for competitors?
Might any pending legislation affect the development of this system?
Are there any aspects of criminal law you should consider?
Are there any labor laws (e.g., working hours) relevant to your product?
17b. Standards Requirements
Content
A statement specifying applicable standards and referencing detailed standards descriptions. This does not refer to the law of the land—think of it as an internal law imposed by your company.
Motivation
To comply with standards so as to avoid later delays.
Example
The product shall comply with MilSpec standards.
The product shall comply with insurance industry standards.
The product shall be developed according to SSADM standard development steps.
Fit Criterion
The appropriate standard-keeper cfertifies that the standard has been adhered to.
Considerations
It is not always apparent that there are applicable standards becausetheir existence is often taken for granted. Consider the following:
- Do any industry bodies have applicable standards?
- Does the industry have a code of practice, watchdog, or ombudsman?
- Are there any special development steps for this type of product?
18 Open Issues
Issues that have been raised and do not yet have a conclusion.
Content
A statement of factors that are uncertain and might make significantdifference to the product.
Motivation
To bring uncertainty out in the open and provide objective input to riskanalysis.
Examples
Our investigation into whether or not the new version of the processorwill be suitable for our application is not yet complete.
The government are planning to change the rules about who is responsiblefor de-icing the motorways, but we do not know what the changes might be.
Considerations
Are there any issues that have come up from the requirements gathering that have not yet been resolved? Have you heard of any changes that might occur in the other organizations or systems on your context diagram? Are there any legislative changes that might affect your system? Are there any rumors about your hardware or software suppliers that might have an impact?
19 Off-the-Shelf Solutions
19a. Ready-Made Products
Content
List of existing products that should be investigated as potential solutions.Reference any surveys that have been done on these products.
Motivation
To give consideration to whether or not a solution can be bought.
Considerations
Could you buy something that already exists or is about to become available? It may not be possible at this stage to make this determination with a lot of confidence, but any likely products should be listed here.
Also consider whether there are products that must not be used.
19b. Reusable Components
Content
Description of the candidate components—either bought from outside or built by your company—that could be used by this project. List libraries that could be a source of components.
Motivation
Reuse rather than reinvention.
19.c Products That Can Be Copied
Content
List of other similar products or parts of products that you can legally copy or easily modify.
Motivation
Reuse rather than reinvention.
Example
Another electricity company has built a customer service system. Its hardware is different from ours, but we could buy its specification and cut our analysis effort by approximately 60 percent.
Considerations
While a ready-made solution may not exist, perhaps something, in its essence, is similar enough that you could copy, and possibly modify, it to better effect than starting from scratch. This approach is potentially dangerous because it relies on the base system being of good quality.
This question should always be answered. The act of answering it will force you to look at other existing solutions to similar problems.
20. New Problems
20a. Effects on the Current Environment
Content
A description of how the new product will affect the current implementation environment. This section should also cover things that the new product should not do.
Motivation
The intention is to discover early any potential conflicts that mightotherwise not be realised until implementation time.
Example
Any change to the scheduling system will affect the work of the engineers in the divisions and the truck drivers.
Considerations
Is it possible that the new system will damage some already existingsystem? Can people be displaced, or affected by the new system?
This requires a study of the current environment. A model highlightingthe effects of the change is a good way to make this information widelyunderstandable.
20b. Effects on the Installed Systems
Content
Specification of the interfaces between new and existing systems.
Motivation
Very rarely is a new development intended to stand completely alone. Usually the new system must coexist with some older system. This question forces you to look carefully at the existing system, examining it for potential conflicts with the new development.
20c. Potential User Problems
Content
Details of any adverse reaction that might be suffered by existing users
Motivation
Sometimes existing users are using a product in such a way that theywill suffer ill effects from the new system/feature. Identify any likelyadverse user reaction, determine whether we care and what precautions wewill take.
20d. Limitations in the Anticipated Implementation Environment That May Inhibit the New Product
Content
Statement of any potential problems with the new automated technologyor new ways of structuring the organisation.
Motivation
The intention is to make early discovery of any potential conflicts thatmight otherwise not be realised until implementation time.
Examples
The planned new server is not powerful enough to cope with our projected growth pattern.
The size and weight of the new product do not fit into the physical environment.
The power capabilities will not satisfy the new product's projected consumption.
Considerations
This requires a study of the intended implementation environment.
20e. Follow-Up Problems
Content
Identification of situations that we might not be able to cope with.
Motivation
To guard against situations where the product might fail.
Considerations
Will we create a demand for our product that we are not able to service?Will the new system cause us to fall foul of laws that do not currentlyapply? Will the existing hardware cope?
There are potentially hundreds of unwanted effects. It pays to answerthis question very carefully.
21 Tasks
21a. Project Planning
Content
Details of the life cycle and approach that will be used to deliver theproduct. A high level process diagram showing the tasks and interfaces betweenthem is a good way to communicate this information.
Motivation
To specify the approach that will be taken to deliver the product sothat everyone has the same expectations.
Considerations
Depending on the level of maturity of your process, the new product willbe developed using your standard approach. However, there are some circumstancesthat are special to a particular product and will necessitate changes toyour lifecycle. While these are not a product requirement, they are neededif the product is to be successfully developed.
If possible, attach an estimate of the time and resources need for eachtask based on the requirements that you have specified. Tag your estimatesto the events/use cases/functions that you specified in sections 8 and 9.
Do not forget data conversion, user training and cutover. We have listedthese because they are usually ignored when projects set implementationdates.
21b. Planning of the Development Phases
Content
Specification of each phase of development and the components in theoperating environment.
Motivation
To identify the phases necessary to implement the operating environmentfor the new system so that the implementation can be managed.
Fit Criterion
Name of the phase
Required operational date
Operating environment components included
Functional requirements included
Nonfunctional requirements included
Considerations
Identify which hardware and other devices are necessary for each phaseof the new system. This may not be known at the time of the requirementsprocess, as these devices may be decided at design time.
22. Migration to the New Product
22a. Requirements for Migration to the New Product
Content
A list of the Cutover activities. Timetable for implementation.
Motivation
To identify cutover tasks as input to the project planning process.
Considerations
Will you use a phased implementation to install the new system? If so, describe which requirements will be implemented by each of the major phases.
What kind of data conversion is necessary? Must special programs be written to transport data from an existing system to the new one? If so, describe the requirements for these programs here.
What kind of manual backup is needed while the new system is installed?
When are each of the major components to be put in place? When are the phases of the implementation to be released?
Is there a need to run the new product in parallel with the existing product?
Will we need additional or different staff?
Is any special effort needed to decommission the old product?
This section is the timetable for implementation of the new system.
22b. Data That Has to Be Modified or Translated for the New System
Content
List of data translation tasks.
Motivation
To discover missing tasks that will affect the size and boundaries ofthe project.
Fit Criterion
Description of the current technology that holds the data
Description of the new technology that will hold the data
Description of the data translation task/s
Foreseeable problems
Considerations
Every time you make an addition to your dictionary (see section 5), ask this question: Where is this data currently held, and will the new system affect that implementation?
23. Risks
All projects involve risk—namely, the risk that something will go wrong. Risk is not necessarily a bad thing, as no progress is made without taking some risk. However, there is a difference between unmanaged risk-say, shooting dice at a craps table-and managed risk, where the probabilities are well understood and contingency plans are made. Risk is only a bad thing if the risks are ignored and they become problems. Risk management entails assessing which risks are most likely to apply to the project, deciding a course of action if they become problems, and monitoring projects to give early warnings of risks becoming problems.
This section of your specification should contain a list of the mostlikely and the most serious risks for your project. Against each risk includethe probability of that risk becoming a problem. Capers Jones's Assessmentand Control of Software Risks (Prentice-Hall, Englewood Cliffs, NJ.1994) gives comprehensive lists of risks and their probabilities; you can use these lists as a starting point. For example, Jones cites the following risks as being the most serious:
- Inaccurate metrics
- Inadequate measurement
- Excessive schedule pressure
- Management malpractice
- Inaccurate cost estimating
- Silver bullet syndrome
- Creeping user requirements
- Low quality
- Low productivity
- Cancelled projects
Use your knowledge of the requirements as input to discover which risks are most relevant to your project.
It is also useful input to project management if you include the impact on the schedule, or the cost, if the risk does become a problem.
24 Costs
The other cost of requirements is the amount of money or effort that you have to spend building them into a product. Once the requirements specification is complete, you can use one of the estimating methods to assess the cost, expressing the result as a monetary amount or time to build.
There is no best method to use when estimating. Keep in mind, however, that your estimates should be based on some tangible, countable artifact. If you are using this template, then, as a result of doing the work of requirements specification, you are producing many measurable deliverables. For example:
- Number of input and output flows on the work context
- Number of business events
- Number of product use cases
- Number of functional requirements
- Number of nonfunctional requirements
- Number of requirements constraints
- Number of function points
The more detailed the work you do on your requirements, the more accurate your deliverables will be. Your cost estimate is the amount of resources you estimate each type of deliverable will take to produce within your environment. You can create some very early cost estimates based on the work context. At that stage, your knowledge of the work will be general, and you should reflect this vagueness by making the cost estimate a range rather than a single figure.
As you increase your knowledge of the requirements, we suggest you try using function point counting-not because it is an inherently superior method, but because it is so widely accepted. So much is known about function point counting that it is possible to make easy comparisons with other products and other installations' productivity.
It is important that your client be told at this stage what the product is likely to cost. You usually express this amount as the total cost to complete the product, but you may also find it advantageous to point out the cost of the requirements effort, or the costs of individual requirements.
Whatever you do, do not leave the costs in the lap of hysterical optimism. Make sure that this section includes meaningful numbers based on tangible deliverables.
25. User Documentation and Training
25a. User Documentation Requirements
Content
List of the user documentation to be supplied as part of the product.
Motivation
To set expectations for the documentation and to identify who will be responsible for creating it.
Examples
Technical specifications to accompany the product.
User manuals.
Service manuals (if not covered by the technical specification).
Emergency procedure manuals (e.g., the card found in airplanes).
Installation manuals.
Considerations
Which documents do you need to deliver, and to whom? Bear in mind that the answer to this question depends on your organizational procedures and roles.
For each document, consider these issues:
- The purpose of the document
- The people who will use the document
- Maintenance of the document
What level of documentation is expected? Will the users be involved in the production of the documentation? Who will be responsible for keeping the documentation up-to-date? What form will the documentation take?
25b. Training Requirements
Content
A description of the training needed by users of the product.
Motivation
To set expectations for the training. To identify who is responsible for creating and providing that training.
Considerations
What training will be necessary? Who will design the training? Who will provide the training?
26. Waiting Room
Requirements that will not be part of the next release. These requirements might be included in future releases of the product.
Content
Any type of requirement.
Motivation
To allow requirements to be gathered, even though they cannot be partof the current development. To ensure that good ideas are not lost.
Considerations
The requirements-gathering process often throws up requirements that are beyond the sophistication of, or time allowed for, the current release of the product. This section holds these requirements in waiting. The intention is to avoid stifling the creativity of your users and clients, by using a repository to retain future requirements. You are also managing expectations by making it clear that you take these requirements seriously, although they will not be part of the agreed-upon product..
Many people use the waiting room as a way of planning future versions of the product. Each requirement in the waiting room is tagged with its intended version number. As a requirement progresses closer to implementation, then you can spend more time on it and add details such as the cost and benefit attached to that requirement.
You might also prioritize the contents of your waiting room. "Low-hanging fruit"—requirements that provide a high benefit at a low cost of implementation—:are the highest-ranking candidates for the next release. You would also give a high waiting room rank to requirements for which there is a pent-up demand.
27. Ideas for Solutions
When you gather requirements, you focus on finding out what the real requirements are and try to avoid coming up with solutions. However, when creative people start to think about a problem, they always generate ideas about potential solutions. This section of the template is a place to put those ideas so that you do not forget them and so that you can separate them from the real business requirements.
Content
Any idea for a solution that you think is worth keeping for future consideration. This can take the form of rough notes, sketches, pointers to other documents, pointers to people, pointers to existing products, and so on. The aim is to capture, with the least amount of effort, an idea that you can return to later.
Motivation
To make sure that good ideas are not lost and to help you separate requirementsand solutions.
Considerations
While you are gathering requirements, you will inevitably have solution ideas; this section offers a way to capture them. Bear in mind that this section will not necessarily be included in every document that you publish.
Subscribe to:
Posts (Atom)
Posts
