What are the different types of requirements and why does it matter?

 

A software product is usually built with a purpose in mind. There is a reason a good number of web application domains end with “.io “. It literally means Input Output.

Your product takes in some raw information and returns more valuable processed information.

As usual, the devil is the details. What does raw information mean? What does output mean?

Scrum typically adopts user stories as its template for expressing its requirements.

This simple structure of:

    As a __
    I want to___
    So that __

Elegantly captures what the software should do and why.

Still, as the product gets bigger and the requirements pile on, I find it useful to impose some categories on the backlog.

In this entry, we will be looking at some categories which I have found to be useful.

User requirements

At iHub, we pride ourselves in our Human Centered Approach. The simple reason is it works.

The software serves people. At the end of the databases, activity streams, object storage etc is a person trying to get something done. Your success is measured by how successful this person is.

It then helps to acknowledge user requirements as a category on its own.

A typical requirement would be

    As a *researcher* I want to *have my results sorted by relevance* so that *I can get my work done faster*

Business requirements

We talk about the wonders of technology, from the aeroplane to the mini computer in our pockets. Yet, I would argue the biggest invention by humans was the enterprise.

Businesses, are the engines of our society, working behind the scenes, they provide us with all our material needs.

No matter how good, the software or how well it serves the users, if the business does not provide value to its owner then it’s as good as dead.

With this in mind, you must seek to also clarify why it is the client wants the software product built in the first place.

This is usually captured in the client’s vision statement. Of this, the software serves only a part of it.

An example of vision statement from Amnesty International

A world in which every person enjoys all of the human rights enshrined in the Universal Declaration of Human Rights and other international human rights instruments. 

If you happen to be contracted by Amnesty International, you need to remember to imbue this inspiring vision in every line of code you ship.

Non-functional requirements

Robert Gardy in his 1992 book Practical Software Metrics for Project Management and Process Improvement

Came up with the acronym FURPS+

This represents:

  • Functionality
  • Usability
  • Reliability
  • Performance
  • Supportability

The “+” in FURPS+ also helps us to remember concerns such as:

  • Design requirements
  • Implementation requirements
  • Interface requirements
  • Physical requirements

The idea is in addition to doing what it does, software is also required to do it well.

How effective do you think Google would be if it took 5 minutes to give you a response to your query?

I believe by categorising your backlogs in this way, you will able to get more ideas on what is to be included in the final product as well as appropriately prioritise the various backlogs resulting from it.

How do you categorise backlogs in your own organisation? How did you handle it? Talk to me in the comment section below or on my twitter @jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Sources of change in a software project

 

Change is an integral part of the software development process. It’s what makes software soft. In fact, change is so important in software that it get’s it’s very own line in the agile manifesto

    Responding to change over following a plan

It’s been a long time since software teams believed in the unchanging quality of requirements documents, but we are yet to fully understand where change comes from and how it affects us.

It costs far much more to make core changes during development than it does at requirements. Boehm and Papaccio estimate it at 50 – 100 times more. Even with the advent of agile techniques, it is still worth it to control change as much as possible.

In this entry we shall be exploring the various sources of changes, this should hopefully help you anticipate and identify impending changes as soon as possible.

Change from the customers

Of all the sources of change, this is the one worth most consideration. The reason is that as a consultancy or even engineering department, you want to harness change as a competitive tool for your client.

No matter how well you run your requirements gathering sessions, there are requirements you are bound to miss. This is because knowledge builds on knowledge ideas on ideas.

To illustrate this point, think of a car. The first car was a very basic box with wheels that happened to move. But from this idea, people began asking questions such as:

  • Why can’t the seats be more comfortable?
  • Why do I have to be hot in the car?
  • Why do I have to manually change gears?

Today, these previously extraneous features are deal breakers.

In the same way, once development has started, your customers are guaranteed to have new ideas as they see your progress.

In this kind of situation, you want to carefully weigh your options. You don’t want to do exactly what the customer wants you may end up always chasing after the new shiny thing. You also don’t want to completely ignore their wishes under the guise that you know best.

Change from sales and marketing

This part particularly affects product companies.

The product owner declares this Big Hairy Audacious Goal

    We will build a one stop best in class application within the next 6 months

This is a great goal and everyone is excited about it. The engineers get to work “banging” it out. Somewhere within the development window, the competitor does a release that you had not even thought about. The sales team also wants to be able to sell the new feature so they insist that is also put in the product after all our product is best in class right?

It is tempting to think of your application as a big checklist of features, this is dangerous because then you will be locked in competition with other firms to produce more and more.

Kelly Walters makes a compelling argument in Agile Principle 8: Enough Is Enough! that you likely don’t need to develop 80% of the features.

Perhaps then the product owner should have come up with a better goal say

    We will build a product in the next 6 months that will improve our customers margins by atleast 10%

Change from developers

Developers, my favourite group!

More than any other stakeholder, developers have the highest intellectual and emotional investment in the project. They are the ones who had to deal with the design flaws, unexplainable bugs and late night coding.

Yet to them, requirements are usually provided as a checklist. In this case am also looking at a list of user stories as a checklist. Without an organising theme, developers will do what they do best, write the best-designed code that they can conceive off.

The problem here is that the devil is in the details. Your DBA may end up writing code that shortens query time from 10ms to 1ms. This is great, except for the fact that no one really specified that they have that requirement. Another example would be where your front end engineer goes out of their way to guarantee that the settings page will work for all screen sizes.

I believe by actively watching out for this sources of change, you will be in a better position to manage them when the changes do come.

What are the sources of change in your own projects? Talk to me in the comment section below or on my twitter @ jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Hidden risks to project success

 

A story is told of a product manager who got a complaint from one of their major clients. The complaint was addressed to the apparent slowness of the app when getting data from the server. As it turns out, the PM knew a code ninja from back in the day. The PM had heard that the ninja has been working on a customized SQL engine that enhanced query performance on products such as his by a magnitude and in some cases even more.

So he had the ninja brought in to demo her invention. The new library proved true and the PM promptly had the developers implement the library on a hotfix that was then released to the major clients.

Once the new app got into production, it’s weaknesses started showing, for some reason the library was updating wrong records. The PMs company got sued, he tried to pass on the suit to the developer but the developer promptly pointed to the copyleft. The company ended up losing millions in the suit and even more from a tarnished reputation.

In today’s entry we will be looking at some basic guidelines to avoid such mistakes when making design decisions.

Fighting complexity with complexity

Software projects are incredibly complex creations. It is tempting to assume that the answer to creating this complex products lies in crafting complex designs. You would be wrong.

The practise of XP explicitly admonishes this belief in their credo.

    I have been surprised many times by how efficient a simple design can be. Simple designs often out perform highly complex yet theoretically optimized designs.

John Gall puts it even better.

    A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

Sometimes a monolithic app is the best answer. Your job as the developer is to deliver business value. Engineering skills are worthless if they can not generate economic value.

Simple designs require deep understanding of the problem you are trying to solve. This is hard work, but worth it.

No design

It is at times easy to confuse the concept of simple design with no design at all.

Doing a project with no design means you accrue a ton of technical debt in the process. As we have discussed in How you pay for technical debt when the debt falls due, your project will not stand.

Lower level languages

Very few developments in the field of software engineering have been able to provide a 10* gain in productivity.

F.Brooks famously stated:

    There is no single development in either technology or management technique which by itself promises even one order of magnitude of improvement within a decade in productivity, in reliability, In simplicity.

This statement was said in 1986. And it held true. But before then the said improvement was actually achieved when compilers were invented. Suddenly developers no longer had to care about machine code, only the business logic that they wrote.

From this era, the field has advanced greatly with successive languages abstracting the machine even more. Modern day languages have syntax that more closely resembles business parlance than scientific jargon.

Yet there are developers out there who want to take us back to the old days. Claims are made of the speed of lower level languages such as C or even worse assembler languages.

Unless you have a very strong case, avoid this languages and the developers who insist on using them like the plague.

Unfamiliar processes and tools

Developers are attracted to new shiny tools. That is a fact. Wether its a new IDE, language or even note taker. We love the novel.

Unfortunately all new tools have unknown kinks. It takes time for the product to mature. Obviously if you stuck to only the tools and processes that you are familiar with, you would become obsolete. With that said it is still better to err on the side of mature tools so that your team can focus on the product you are building rather than figuring out if whether the issue you are dealing with is a bug or a feature.

In my experience the above are the design problems that keep on creeping up. Tell me about your own experience on my twitter @jchex or on the comment section below.

Facebooktwittergoogle_plusredditpinterestlinkedinmail