Brickwork Ventures GmbH, Winterthur / Switzerland

Requirements Management
in a Start-Up
Should start-up companies care for a systematic
requirements management process? And if so,
how?
2
What is Requirements Management
If you build a product, no matter whether it is a piece of software or a jet
fighter, you will have a hard time trying to achieve a result which pleases
everyones expectations and fulfils everyones needs. Expectations are almost
always subjective, and more often than not contradictory. Especially in the
beginning of a project, where many important decisions have to be made,
concrete insights into the properties of the final products are rare.
That is, the product exists as a mental picture in the brains of the involved
people: As in painting, they are highly individual masterpieces; depending on
the personality and position of the painter, some are rather impressionist,
some rather realist, and some are more colourful than others. In both genres,
quality normally varies considerably.
The level of detail does not say anything about quality: A strategy paper or
project charter may be succinct, elaborate and providing good guidance, or it
may be fuzzy and blah. On the other hand, very detailed specifications may be
accurate, efficient to implement and impressive, but many are difficult to
understand, full of prematurely anticipated decisions, or simply going into the
wrong direction.
Stakeholders refer to their internal images all the time: when they talk about
the project or product to express their wishes, their needs and expectations.
When they control progress of the project they compare their perception of
reality to their image of the to-be-state of affairs. It is therefore clear that things
may turn out very badly if the various personal paintings are inaccurate,
contradictory or far from reality: the risk is, that results will not meet
expectations, which leads to frustration, cost overruns, unhappy customers,
problems.
Our understanding of Requirements Management is to align these subjective
conceptions by bringing them to paper, that is, describe the properties of the
end product as seen from various angles and perspectives, as comprehensively
as possible and by communicating them appropriately to stakeholders.
Appropriately means that depending on role and position, a stakeholder has
specific interests, limitations and pain points: It is sufficient to show a nice
impressionist painting to a high-level manager with the goal of building a very
nice garden in front of the office to impress customers. It is probably not
enough to use the same painting when communicating with the gardener, who
expects clear ideas about what is possible, what is not, and how much it may
cost in the end.
3
The term requirement highlights two other aspects:
that we should carefully distinguish between what is required
(requirement) and how it will be finally implemented (separation of
requirements and solution design);
that they represent claims of various stakeholders rather than universal
properties of a product
While certainly right, we believe that these points should be considered, but not
dogmatically so. A common philosophical debate is the following: How concrete
may the requirements be? If it is only about the what, and by no means about
the how, is it then strictly forbidden to use concrete properties or abilities as a
requirement? What about using mock-up screens to illustrate a requirement?
Many orthodox requirements engineers would probably consider them an
absolute no go. The risks cannot be neglected: getting concrete means to a
certain extent to compromise flexibility at a later point in time. Expectations
evoked by showing mock-up screens may be difficult to manage.
On the other hand, we have come to believe that a pragmatic approach pays
out in the end. First of all, what ever helps to create and communicate a vision
of the end product to various stakeholders, should be used. Drawing a clear
picture of the (partly) unknown and share it with all stakeholders to have every
one on the same page thats in my view the most important tasks of RE and
anything that helps to that end should be done. Yes, there are risks to it, but
also advantages.
4
What is a Start-Up Company
The coffee shop around the corner that opened a few weeks ago isnt
necessarily one, despite its owner aged 25. Neither is a manager or ex-
consultant quitting his job just to start his own management consulting shop.
Developing a novel method for the treatment of cancer based on a new, so far
untested technology, certainly is one. So is probably a tech company building
an application that can not be bought from the shelf unless it does so on
behalf of someone paying for it (because then, it is again a simple service shop
offering custom software development services to its clients).
Let say then a start-up is a company investing in a fully or partly innovative
product or service with a partly unknown and volatile set of features, and trying
to sell it to yet unknown buyers. Put differently: You dont know what exactly it
is going to look like, you dont know whether someone is going to buy it, but
you are ready to lose your money for the uncertain prospect of making a
business out of it.
There are different approaches to face this kind of uncertainty:
The detailed approach is to write a business plan and make some
reasonable assumptions and hypothesize about what the market
requires. Maybe you test them in the field, e.g. by doing extensive
interviews with whom you think will be the buyer of the product.
Just do it. The just-do-iters are people so much tired of writing these
presumably sound business plans which look nice and turn out wrong,
that they decide: it is lottery anyhow, why lose time doing tons of
worthless analysis on the paper, just do it and we will see where we end
up.
We believe the most promising approach is a compromise between the two:
prototyping is helpful to get early feedback from the market, which is key to any
start-up. On the other hand, sound strategic and short-term planning is
indispensable.
We believe there is a big advantage in prototyping, and we try to apply it to all
our new ventures. On the way to the prototype, we use an agile approach
already discussed in our paper Development Speedboat.
Agility and planning are not contradictory: Agility does not make planning
impossible, and neither does planning compromise agility. The notable
differences are that
5
We plan what work can be done with the available time, where
traditional planning is the other way around: we would start by figuring
out how long it takes to get the work done;
We do not maintain comprehensive documentation of requirements to
check them against reality only after important milestones: since we
have a running prototype every day and customers (stakeholders) can
see a preview of the end product much more often than in the
traditional approach, comprehensiveness is not important;


6
Requirements in a Start-Up
We have seen what requirements are, and we understand the specifics of start-
up companies how do we bring these two things together? First of all, the
traditionalists and the just-do-iters are trivial ones: Either they will follow
traditional techniques or they will not care much about requirements at all. We
will therefore concentrate on prototyping.
In terms of requirements, building a versatile prototype can lead to opposing
opinions:
It is not yet clear what should be built really, so why bother about
requirements in the first place?
The prototype will evolve towards a range of possible options, some of
them are known, others will come in as surprise. If we have 5 options in
mind, we should think about the requirements in 5 different scenarios
specifying 5 scenarios per requirement is of course costly, but like with
trading options, each has a value that can possibly be realized into a
gain, and what counts is the expected value of all gains minus all costs.
We have come up with the following principles:
Build a strong baseline. Thinking in options is good, however, efficient
development (not only coding, but also business modelling, marketing, etc.)
calls for a concrete, more or less stable baseline assumption of what the
product should be and what it should not be. Given the many options a green-
field start-up has, this is not an easy task to do. However, it is a management
task, not a task of the developers or of any other operational staff.
Classify requirements by layers. Some of the principles or assumptions
that we establish during the conception of the product are so fundamental that
it will be very hard to change them later on in the process. Example: In our
Qwestmark project, we initially discussed whether a Qwestmark account should
have a type: either it would be a requester account (for organizations that
procure services and goods via Qwestmark), or a supplier account (for those
who supply these goods and services). What if we will find out that large
customers with company accounts will be on both sides, i.e. in some projects,
they are suppliers, and in others, they are requesters? If we decide to put this
requirement out of scope and give a type to an account, this would be quite
hard to sort out later on, since the whole logic of the user interface would be
different (or ugly in the trivial case: indicate your role on login). Other
requirements are rather on the hull than in the core: small adjustments to the
GUI for instance.

7
Use just in time requirements As in other agile projects, we build the
requirements on the go, i.e. when we discover that some feature should be
included, we specify it. We are not trying to get a comprehensive list of features
to be built from the beginning.


8
Documentation
The main problem with documentation is that barely anyone reads it! Why
wasting time writing it, then? Of course it is never wrong to say things like all
has to be properly documented and in principle, this is true. However,
keeping a comprehensive documentation up to date is only possible in theory.
Luckily enough, start-ups have one problem less: there is much less internal
politics. We do not have to commit and deliver on initial artefacts such as
detailed use case descriptions (and to spend valuable time on explaining ex
post why 50% of them turned obsolete or were contradictory or overlapping
with responsibilities outside our context). We do not have to deliver fancy
documents just to satisfy bureaucratic desires. We can really generate
documentation only where we think it creates added value.
Documentation is key and it is one of our main communication tools. But it is
costly to produce it and to read it. Therefore, the important stuff should be well
documented, but only the important stuff. To allow for the required quality, the
necessity of documentation should be kept to a minimum. The following
principles help us:
The value of consistency or the fly in the soup. Similar things should be
implemented consistently throughout the whole application. This principle
applies to the program code as it does to the user flow, to the database
structure and to any other internal or visible structure of the application. If the
questionnaire entity requires an attribute APPROVAL_DATE, which is nullable,
to steer its approval status, then, the supplier list entity will also have an
APPROVAL_DATE, not a APPROVAL, and not a DATE_OF_APPROVAL, and not
even an APPROVALDATE! And it will also be nullable, with null interpreted in
exactly the same way. The human brain is very good in discerning patterns
using them boosts efficiency. Since our brains are even better at detecting
broken patterns, the slightest anomaly will distract us from the essential and
make us inefficient.
Dont state the obvious. Many documentation artefacts take so much time to
discuss the obvious, but miss the important. After having crawled through
countless lines of mediocre prose, you still lack the essential link to understand
what they did. The Yes thats all very clear to me but would someone tell me
why the hell feeling is the shared suffering of the rare species of
documentation readers around the world (by the way, if you kept up reading to
this point, I will invite you out for coffee just send the code word it was hard,
9
it was boring, but I kept up reading, and now I want something back to
camporelli@brickwork.ch)
1

Concentrate on the core requirements. Among all requirements we
formulate during the course of the project, many of them will be refined, or
even removed or replaced after a while. In Qwestmark, where we currently have
ca. 1100 requirements formulated, a whole lot of them are out of date. They
are documented in our tasks management system (closed features in JIRA) as
well as in a history folder on the file system, thats it. On the other hand, we
keep a small amount of documents in a special core folder, containing
everything we think is core and not obvious. For instance, what mechanism is
triggered when questions that are shared
2
by different (possibly unrelated) RfPs
within a company and then changed by one of the RfPs? On the other hand,
things like How does the login mechanism work are core, but quite obvious
3
.
The relevant core requirements however are documented in a detailed way, and
kept up to date.
1
If you even read footnotes, you will get an extra cookie (code: with cookie!)
2
Qwestmark allows questions to be reused by RfPs within the same company (e.g., what
operation systems do you support?) if the question is not explicitly excluded from sharing by
the project (=RfP) manager. Of course, changing such a question potentially affects other users.
Qwestmark uses a mechanism that clones the questions if they are already in use by different
RfPs.
3
Of course not trivial there are different authentication methods, what hash algorithms are
used for the passwords etc. but any experienced programmer will find it out quickly when
looking at the code.
10
Conclusion
We asked ourselves three questions: What is requirements management, what
is a start-up, and how do they make sense together. We argued that while in a
hyper-agile setting, systematic requirements management may be questionned,
it is still worthwhile to do it. Requirements should be layered according to their
importance and stability. Documentation should be done carefully, but only
where needed. Consistency and self-explanatory design helps to avoid massive
amounts of documentation that no one will ever read.
We hope that our thoughts will be beneficial to anyone creating, developing or
starting new products! As always, any comments are welcome just drop us a
line to share your opinion on the matter.
11
Contact us
Did you find this article useful? Do you agree or disagree to specific points? We
are always happy to get feedback and to discuss:
Brickwork Ventures GmbH
Archstrasse 2
8400 Winterthur
Switzerland
http://www.brickwork.ch
info@brickwork.ch
Author
Marcel Camporelli is Managing Partner and Co-Founder at
Brickwork Ventures LLC in Winterthur, Switzerland. He works as a
consultant and business analyst for major corporations and is
involved in a number of start-up ventures.