Gathering and managing requirements

User requirements and analysis is often considered to be the starting point for the systems development process. There are many requirements management frameworks most of which are basically templates and checklists for gathering and recording a variety of user-oriented data.

Examples:

• Atlassian's Confluence/Jira offers a sophisticated holistic model for capturing, storing, presenting requirements for future development. See this example from the Confluence/Jira tutorial (link).
• A typical/conventional/traditional requirements document; source - a student engineering project (link)

A selection of typical requirements documents.

Some musings on requirements:
Product requirements can be thought of as a rather unique kind of shopping list; a shopping list written by (more often on behalf of) the user, and written for (usually by) the developer to deliver. Taking the analogy further; the requirements shopping list is for a shop where the shelves are initially empty because the things the user wants haven’t been made yet. Alternatively there may be something on the shelf that approximates what the user wants but it’s not quite right and needs to be customized. To compound this seemingly odd situation we may also find that product requirements may be written (created) by someone who is neither the customer (user) nor the designer (developer). In this situation those charged with requirements capture have a lot of responsibility and power to influence the design process. Product requirements lie between the user and the designer and act as a communication device between the two. The requirements document is merely a representation of a potentially unbounded set of product requirements therefore the process used to create the representation is perhaps more significant that the document itself.

Links of interest?
https://svpg.com/the-end-of-requirements/

Supporting Exercise?

Share a file or post a link to an example of an actual product requirements page or document. Note. Examples out there might be titled 'pitch' or 'design' (e.g. a game design document), rather than 'requirements' but the substance of the subject matter described in the document will be features, needs, constraints etc.

General comments on doing field research

On learning about methods

On methods; I recommend you identify a published research example and adapt it. And look carefully at the example's own bibliography too. The methods literature is broad. You will take ownership ofdiscovering your methods' background, select an informing literature and decide for yourself about method suitability etc.

Each of us is expected to delve into the literature on the different methods available and on adapting these findings to our own topic. The reasons for this are various but primarily because research methods for product design and scientific studies is a very broad area with huge variation and there is no way to teach methods without limiting or biasing your own research journey (see comments below on the overuse of surveys and questionnaires). Educationally I expect each researcher to identify, study and develop expertise in the methods they employ. By taking ownership of this you become authentically involved in the process of professional and scholarly research. You will discover the background to various methods, select the publications that inform your own research design, decide through experimentation what methods are suitable and feasible for your own research context.

Some comments by way of general orientation to a research exercise:

• Be curious and open to discovery
• Goal oriented analysis often yields interesting findings.
• Be open to identifying insights, deep insights, particularly "what I learnt".
• Look out for the unexpected, things that are puzzling, aberrations. 
• Self-reporting can be hugely insightful, this can be researcher self-reporting or respondent/subject self-reporting.
• Don't get side-tracked by 'annoyances' when there is an elephant in the room.
• When making recommendations or advising on solutions
• Contrast with comparable experiences, goals, solutions from other industries.
• Contrast with completely incomparable solutions from completely different settings.
• Avoid 'selling' a new tech system as if it is a holy grail or nirvana solution. All tech systems have their failings, you may simply be changing the source of your pain, not taking it away.
• There is huge value in a quick-dirty prototype. 
• Use paper sketches, paper prototypes, mock-ups, from low to medium to high fidelity.
• Design ideas (sketches, mock-ups, prototypes) are used for feedback, for learning.
• If a design proposal is quite narrow, if so then it must be very focused, well argued, and insightful.
• NO DANCING BEARS! For an explanation see Alan Cooper's book "The Inmates are Running the Asylum" (search link)
• Respect your research subjects' privacy-identity
• It's generally seen as good practice to anonymise your interviewees if putting information in the public domain unless it is absolutely necessary for some reason.
• I recommend redacting personal identities from reports and papers.
• Be aware of copyright and attribution
• You cannot post other people's copyright material online.
• If you 'copy-paste' content from someone else make sure you surround it with quotation marks and include a citation or attribution.
• Do please make posts on your websites that are your own writing. 
• Be aware of and comply with copyright law and conventions for fair use, attribution etc.

On Surveys and Questionnaires

I am not particularly interested in student projects that use surveys or questionnaires as the main or even as supporting research methods. 

Surveys and questionnaires are a tertiary research method and rely on the laws of large numbers and/or access to large representative population pools. Survey/questionnaire methods are explicitly closed-ended in that they imply limited sets of allowable data/responses. Unfortunately these methods are rarely accompanied with a necessary introspection by the researcher of prior assumptions, or reflection/statement of researcher's epistemological/ontological assumptions that may skew or predispose the design of data collection to produce implicit results. A research design may in fact generate (produce, reify) the very objects it seeks to reveal.

It is also rare that we see well justified and well designed questionnaires or surveys. In fact these methods require that that the researcher has already studied (through literature review) or actually conducted extensive primary empirical research and/or carried out medium scale studies before resorting to survey/questionnaire. The findings of prior studies provide the justifications for determining what, why and who to ask. There will be clear connections between foundational research findings and the very design of a survey/questionnaire instrument. The content and sequence of each question is there for a valid research reason. The method is an inherently closed style of questioning and is therefore a kind of 'forcing function'. It produces limited responses responses to focused questions and therefore carries the risk that you will only detect what you expect to find, the method is quite literally self-determining and often results in poor science.

The design of surveys and questionnaires must needs be subjected to scrutiny, refinement and quality checking in order to avoid problems ranging from avoiding leading questions through to establishing construct validity. For example, is it essential for the research that you capture the respondents gender? Why? Is this justified? If so how many categories are you providing? Male/Female? Does the respondent have to answer or can they opt out? If so how does this affect the data and your analysis of it?

Surveys and questionnaires have their uses, for example where the concepts are well defined, not subject to misunderstanding (ref. construct validity), and the questions being addressed can usefully be asked of a large sample population. Therein lies my last bugbear with survey/questionnaire, sample size. A survey with 8 respondents is technically useless unless the whole population is 8. Statements based on small sample sizes are likewise in general useless unless you are sampling small absolute populations. Plus, survey responses are often presented in ways that mislead us as to their significance, for example, "100% of survey respondents answered yes" creates a different impression from "8 survey respondents answered yes".

So when does a survey sample size reach statistical relevance? The answer to this question depends on the margin of error threshold you seek to pass. Notice when talking about populations we generally refer to the sample size, a subset of the population. The implication being that we don't expect to be able to contact every single member of a target population, merely a subset. So what sample size do we need to reach to make reasonable inferences about the entire population? The margin of error or confidence level desired are in fact functions of population size; see "survey population/sample size calculator" for further information.

Survey population-sample size calculators

The Difference between Citing References and Field Data

References and citations should relate to the subject matter being written about. Field data and interviews etc. gathered from a field study site does not constitute reference material in the same way; in this case a quote from the data is simply data not a citation. Similarly survey results are only included where relevant to the arguments or analyses being made, the entire survey with responses should not be appended to the paper. Research instruments and the gathered results may, if desired, be included in an appendix at the end of the document.

A different take on requirements...

Marty Cagan from SVPG has definitely taken a provocative stance with this post (link). He suggests that we should stop thinking about the job of product management as one of gathering and documenting requirements, that we should think instead of met and unmet needs! Furthermore that solutions may be inspired by technology and/or customers, suggesting to me at least the the product manager's remit extends to how customers use the product, not just the outward technical feature/properties of the product.

I'm impressed by the usefulness of this contrary perspective, it seems to make a subtle but valuable shift in the product manager's orientation and concerns.

Exercise: Requirements Design Trade-off

This exercise has been adapted from Alexander’s ‘Notes on the Synthesis of Form’ (Alexander, 1964); the simple design problem from section 1 ‘the need for rationality.’ Alexander’s classic design tetrad characterises trade-offs between the major product requirements: simplicity, performance, features, economy.

Objective
Organise, model and explore the interrelationship between different requirements.
Requirements/Design Preparation
1. In groups of 2 or 3 categorise the following non-functional requirements for an imaginary high tech product.
Statement of non-functional requirements

1. A simpler product (system, service, device) will be easier to manufacture and operate.
2. A simple product with fewer features is going to be less costly to maintain.
3. A simple product is easier to construct as it has fewer features.
4. Greater system performance or power is achieved by including more (advanced) features.
5. A highly optimised product is difficult to improve, change, fix or maintain without degrading its performance.
6. A simpler product does not deliver as many features or options as a more complex product.
7. A simple product using fewer specialised parts will not perform to as high a level as one using specialised optimised parts and sub-systems.
8. Adding more features makes the product more difficult to maintain.

2. Consider following product requirements categories: Simplicity, Performance, Feature Set, Build/Operate Economy.

3a. Map these non-functional product requirements to the following categories: Simplicity, Performance, Features,  Economy (+ or - for complement or conflict). 

3b. (Online version) Use a Jamboard to draw the trade-off diagram (link). Each group draw numbered arrows with plus or minus indicators (+/-) to complete the diagram, illustrating the relationships between the requirements listed. 

Discussion:

• Do requirements influence design decisions?
• Is a unique solution possible satisfying all requirements?
• Do requirements specify design?
• Is it possible to overcome contradictory requirements?
• Would more detail enable us to overcome contradiction?
• Will computer modelling of requirements enable conflicts to be resolved?
• Does the design of the product limit which requirements can be delivered?
• Is there always a trade-off between requirements and design?

Reference:
Alexander, C. (1964) Notes on the Synthesis of Form, Cambridge, Massachusetts, Harvard University Press.

---

A Collage of Outputs from the Requirements Exercise

Requirements are the devil.

Questions that keep coming up from business people managing development projects:

"shouldn't I build a blueprint a software company could use to directly build the plattform?""Isn't focusing solely on User Stories letting the software company a little bit too much freedom regarding design?"
"I think I need to describe the processes between differrent modules, how do I do this with just User cases?"
"Where can I define the database structure and security issues?"

In response, to be clear; of course you can design your interface, you can even design your database schema, both of those activities are useful and provide a basis for starting the project. BUT neither are sufficient to bring the project to market nor are they likely to be retained if you actually produce the project.

Why? Because you hire specialists to do design for you. The thing you bring is your judgement, appreciation for use and usability, the specialised domain knowledge you possess, your commitment to the project, your access to financial resources or gateway into a market etc.

In my opinion you shouldn't even be thinking in terms of modules, database structure or security solutions. Although you should be conscious of the need for all of them to be present or resolved.

Unless of course you are the developer.


As a product manager or project leader for development, at some stage you are going to have to capture basic requirements (look back to this post).

But be careful you don't stray into specifying the system design!
Relax, the people you hire to do the development should have the freedom to offer the best design they can. Note that User Experience design is a separate specialisation from application architecture design. You should actually bring in different specialist skills for these two very distinct disciplines.

The current practice for a system requirement is that it be:
* uniquely identifiable
* that it identifies the customer who requires it and why
* that it is expressed in goal driven terms rather than by specifying the implementation
* e.g. that you express it as a 'use case' using the storycard syntax "as a.. I want to.. so that.."

The same goes for functional and non-functional requirements. The main difference is in how testable they are.

Nearly everything else you produce for project planning and development is a design artifact not a requirement.

Reflect on this provocative opinion piece by Michael Schrage

"...have the wit and courage to ban requirements from every systems, process and innovation proposal made to top management. (Instead) Put use cases front and center in your value creation efforts."

blogs.hbr.org 12:31 PM Tuesday September 6, 2011

Also see this post on an underlying theory for requirements.