Executive in wait

Requirements Trawling September 2, 2005

• When you try to discover the requirements for any kind of product the difficulties are even more complex because the source of the requirements is not just one person, it is all of the people who are stakeholders in the project.
• And all of these people have their own view of what is important, along with their own experience, prejudices and views of the world.
• The aim is to discover all the requirements that are relevant to the product that we intend to build as early as we possibly can
• However it often happens that requirements which could have been known
  about earlier are not discovered until after the product has been built.

Conscious requirements

• The type of requirement that a stakeholder is most likely to communicate is what we call a conscious requirement.
• A conscious requirement is something the stakeholder is particularly aware of. This might be because it is one of the reasons for building the product like “I want the camera to fit in my handbag”. Or it might be because a current product has a shortcoming – “I want the battery to last longer”. Or maybe it is because the stakeholder is aware of a new piece of technology – “I want the camera to be able to take digital photographs”. In all these cases a particular stakeholder is conscious of a requirement because of his particular view of the world, consequently it is something he is likely to mention

Unconscious requirements

• Another situation is when a stakeholder does not mention a requirement because he does not realise that he has it. Think of it as an unconscious requirement.

Reasons for Unconscious requirements:

• Reasons for this situation might be that the stakeholder is so used to having this requirement satisfied that he no longer thinks of it as a requirement.
• If he is so used to his camera automatically rewinding at the end of the film, then he is less likely to articulate that requirement. But if you deliver a camera that does not rewind then he is amazed. How could you possibly have missed that requirement when surely anyone would know it is necessary.
• The problem of unconscious requirements happens often when the stakeholder knows a lot about the subject matter and makes assumptions that everyone else has the same knowledge.
• Another reason is because it is sometimes very difficult to tell someone all the details about something you know a lot about because you feel that maybe you are patronising them. You feel that surely they know
  that and you might be boring them by even mentioning it.
• Yet another reason might be that the stakeholder does not understand what an existing product does and therefore assumes that any new product will maintain the status quo.

Undreamed requirements

• If a stakeholder has a fixed idea of what he believes is possible then he is unlikely to mention requirements that he thinks cannot be carried out within his understanding of the constraints.
• “No point in mentioning that I would like the camera to be waterproof – I know it’s not possible within the budget”.
• Undreamed of requirements will not be invented by stakeholders who fall into the category of customers or end users.
• Instead other stakeholders like technical specialists and developers will be the inventors and suggestors of undreamed of requirements.
• Unless we encourage stakeholders to imagine these undreamed of
  requirements, they are unlikely to surface until later in the product’s lifecycle

Techniques for discovering requirements

• The most traditional technique for trawling for requirements is interviewing the stakeholders. The intention is that you ask the stakeholders what they want and they tell you their requirements.
• Although this is a useful technique in many situations, for all the reasons
  already discussed this one technique cannot hope to uncover all the requirements.
• A Variety of Trawling Techniques are:
  Abstraction
  Apprenticing
  Business Events
  Brainstorming
  Family Therapy
  Mind Mapping
  Interviewing
  Neurolinguistic Programming
  Reusing Requirements
  Simulation Models (scenarios, prototypes)
  Soft Systems
  Systems Archaeology
  Use Case Workshops
  Video
  Viewpoints

Apprenticing
Apprenticing uses the idea of a master craftsman and an apprentice. The apprentice observes what the master does, asks questions and then tries to learn the work by doing some of it.

Brainstorming
The purpose of brainstorming is to use the group effect to generate good ideas and to solve problems.

Guidelines for brainstorming are:
1. Don’t evaluate
2. Don’t clarify or seek clarification
3. Go for zany ideas
4. Expand on each other’s ideas
5. List every idea
6. Avoid attaching individual names to ideas

Brainstorming is a particularly effective technique if you are inventing a product and you are trying to explore and understand the potential market.

Mind Mapping
When you are observing, listening or interviewing you normally take some kind of notes to help you to recall and refine your understanding. However taking notes that you can make sense of afterwards is not easy.

Reusing Requirements
If you define your requirements using a consistent approach, then you have the opportunity to reuse requirements.

Suppose, for example, you have an atomic requirement with a well-defined fit
criterion (measurement). Then it’s possible that the same requirement could be relevant either in another part of the same project or in a different project.

Summary

• Interviews are good for conscious requirements
• Apprenticing is likely to uncover unconscious requirements because the requirements engineer will observe requirements that nobody mentions because they are very familiar.
• Brainstorming is very good for undreamed of requirements because it helps to free people from preconceived ideas and encourages them to dream.

Requirements for effective testing September 2, 2005

• If the software is based on inaccurate requirements then, despite any amount of testing, the software will be unsatisfactory.
• If we have a consistent and well-defined way of specifying requirements then we can involve people with testing expertise early in the project.
• A tester can test anything provided he has a set of criteria against which to test.
• In other words we can test a specification to establish whether or not it is a
  specification.
• Without some consistent agreement on what you intend your specification to contain it is impossible to test the quality of its contents.
• The aim is to discover problems like ambiguous requirements, missing requirements, inconsistent requirements – and to raise questions early rather than later on in the development process when it takes much more effort to deal with them.
• Here are some testpoints that you can build into your quality gateway:
• Does the specification contain all the requirements components?
• Does the specification contain all the relationships between components?
• Are all types of requirements defined?
• Is each requirement uniquely identifiable?
• Does each requirement contain all components on the shell?
• Are all the event inputs and outputs defined?
• Can you trace the product use cases back to the business events?
• Are the terms used consistently?
• Is each requirement really a requirement or is it a solution?
• Are conflicts between requirements identified?

Requirements Analysis Overview August 26, 2005

Introduction

• Its all the tasks that go into the instigation, scoping and definition of a new or altered computer system
• Successfully completing a “requirements analysis” task is a challenge
• In the first place, it is not easy to identify all the stakeholders, give them all an appropriate form of input, and document all their input in a clear and concise format
• Studies of previous projects reveal that costs and technical risks can be reduced through rigorous and thorough up-front requirements engineering

General problems

• The right people with adequate experience, technical expertise, and language skills may not be available to lead the requirements engineering activities
• The initial ideas about what is needed are often incomplete, wildly optimistic, and firmly entrenched in the minds of the people leading the acquisition process
• the difficulty of using the complex tools and diverse methods associated with requirements gathering may negate the hoped for benefits of a complete and detailed approach

Stakeholder issues

• Users don’t understand what they want
• Users won’t commit to a set of written requirements
• Users insist on new requirements after the cost and schedule have been fixed
• Communication with users is slow
• Users often do not participate in reviews or are incapable of doing so
• Users are technically unsophisticated
• Users don’t understand the software development process

Developer issues

• Software developers and the end user often have different vocabularies. Consequently, they can believe they are in perfect agreement until the finished product is supplied.
• Software developers often try to make the requirements fit an existing system or model, rather than develop a system specific to the needs of the client
• Analysis is often carried out by programmers, rather than business analysts. It is often the case that programmers lack the people skills and the real world knowledge to understand a business process properly

Solutions

• One of the solutions to this problem has been recognising that requirements analysis is a specialist field best carried out by experts, i.e. business or system analysts, who could bridge the gap between the business and IT (Information Technology) worlds
• Modern techniques introduced in the 1990s like Prototyping, UML, use cases, and Agile software development seem to offer more promise

Main Techniques

• Requirements analysis can be a long and arduous process
• The requirements specialists do their work by talking to people, documenting their findings, analyzing the collected information to discover inconsistencies and oversights, and then talking to people again
• This process can go on for a while, and may continue throughout the life cycle of a system.
• New systems change the environment and relationships between people, so it is important to identify all the stakeholders, make sure you take into account all their needs; and ensure they understand the implications of the new systems
• Frequently, this objective is not met because:
• there is not enough talking, and important needs are overlooked when the system is implemented; and/or
• there is not enough descriptive feedback, and the users are disappointed by the new system’s characteristics
• Analysts can employ several techniques to get the requirements from the customer:

1. Interviews
2. Requirements workshops
3. Creating requirements lists.
4. Prototyping
5. Use cases

Stakeholder interviews

• Stakeholder interviews are obviously necessary in requirement specification
• However, in any large system a number of individuals need to be interviewed, which increases the time and cost; but more importantly almost always this reveals major discrepancies with regard to how the existing business process works and how it should work in the future
• Also different users might have differing or even contradictory requirements.

Requirement workshops

• Therefore where systems are complex the usual method is to use requirement workshops, where the analyst brings the main stakeholders in the system together in order to analyse the system and develop the solution
• Such workshops are ideally carried out off site, so that the stakeholders are not distracted. They usually have a facilitator to keep the process focused, a scribe to document the discussion, and usually make use of a projector and diagramming software. Often multiple workshops are required to bring the process to a successful conclusion
• Requirements workshops are considered to be a very useful technique which can save significant time. However, it can be hard to get all the required stakeholders together at one time.
• A more general weakness is that some stakeholders do not contribute forcefully enough in workshops and their requirements will not receive the appropriate attention, inevitably producing a limited solution
• Additionally, while requirement workshops are an excellent technique for modelling the existing system, they are not so useful for defining the nature of the solution

Contract style requirement lists

• The most common way of documenting requirements has been contract style requirement lists.
• In a complex system such requirements lists can run to hundreds of pages
• Strengths:
• Provides a checklist of requirements.
• Provide a contract between the project sponsor(s) and developers.
• For a large system can provide a high level description
• Weaknesses:
• Such lists can run to hundreds of pages. It is virtually impossible to read such documents as a whole and have a coherent understanding of the system.
• Such requirements lists abstract all the requirements and so there is little context
• This abstraction makes it impossible to see how the requirements fit together.
• This abstraction makes it difficult to identify which are the most important requirements.
• This abstraction means that the more people who read such requirements the more different visions of the system you get.
• This abstraction means that it’s extremely difficult to be sure that you have the majority of the requirements. Necessarily, these documents speak in generality; but the devil as they say is in the details.
• These lists create a false sense of mutual understanding between the stakeholders and developers.
• These contract style lists give the stakeholders a false sense of security that the developers must achieve certain things. However, due to the nature of these lists, they inevitably miss out crucial requirements which are identified later in the process. Developers use these discovered requirements to renegotiate the terms and conditions in their favour.
• These requirements lists are no help in system design, since they do not lend themselves to application.

Prototypes

• Prototypes are mock ups of the screens of an application which allow users to visualize the application that isn’t yet constructed.
• Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built.
• Problems:

1. Managers once they see the prototype have a hard time understanding that the finished design will not be produced for some time
2. Designers often feel compelled to use the patched together prototype code in the real system, because they are afraid to ‘waste time’ starting again.
3. Prototypes principally help with design decisions and user interface design. However, they can’t tell you what the requirements were originally
4. Designers and end users can focus too much on user interface design and too little on producing a system that serves the business process

• Prototypes can be flat diagrams (referred to as ‘wireframes’) or working applications using synthesized functionality
• Wireframes are made in a variety of graphic design documents, and often remove all colour from the software design (ie use a greyscale colour palette) in instances where the final software is expected to have graphic design applied to it

Use cases

• A use case is a technique for capturing the potential requirements of a new system or software change
• Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal
• Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert
• Use cases are often co-authored by software developers and end users.
• Each use case focuses on describing how to achieve a single business goal or task
• From a traditional software engineering perspective a use case describes just one feature of the system.
• The degree of formality of a particular software project and the stage of the project will influence the level of detail required in each use case.
• A use case defines the interactions between external actors and the system under consideration to accomplish a business goal
• Actors are parties outside the system that interact with the system; an actor can be a class of users, roles users can play, or other systems.
• Use cases treat the system as a “black box”, and the interactions with system, including system responses, are as perceived from outside the system
• This is deliberate policy, because it simplifies the description of requirements, and avoids the trap of making assumptions about how this functionality will be accomplished
• A use case should:
• describe a business task to serve a business goal
• have no implementation-specific language
• be at the appropriate level of detail
• be short enough to implement by one software developer in single release.
• Use cases can be very good for establishing the functional requirements; however they are not suited to capturing non-functional requirements.

Stakeholder identification

• In the early days systems were built for the projects sponsor(s), who were usually management types
• Many systems have been designed by managers with little or no contributions from the eventual users; these systems have tended to fail horrendously
• It is increasingly recognised that stakeholders do not just exist in the organisation the analyst is hired by
• Other stakeholders will include:

1. those organisations that integrate (or should integrate) horizontally with the organisation the analyst is designing the system for
2. any back office systems or organisations
3. higher management