Traditional software engineering literature states that a software development project starts with a customer need which is 'translated' into a set of requirements. These requirements then are given to a 'development team'. After a period of time, this team will deliver a software system that will make the customer happy. And everyone lives happily ever after.
What is wrong with the above scenario? It tends to simplify and gloss over some critical issues.
1. Users are not always clear about the problem. This would mean that the information they provide is incomplete or comes as a personal view point.
For example, If H. Ford asked the general population what they really needed most in 1890 - the answer would have been "a comfortable horse carriage". As an answer this is quite valid, however the real issue is the definition of "comfortable". It could mean "less smell", "better suspension", "softer seats", "air conditioning" and the list would go on. One aspect is certain -- most will not be thinking in terms of "an internal combustion engine", "car radio", "DVD player" etc.. The reason is mainly lack of proper awareness of the latest advances in engineering (or the fact that a better technology is not available), along with the natural tendency of the human mind to think within a constrained framework which is determined by the training/education/emotional state. The key point here is the fact that they asked for a "horse carriage" -- the elimination of the horse was never in their minds.
Good software is built by teams that take input from the clients and integrate that with the current advances in technology to produce a solution that is 'different' and may often break the innovation barrier.
2. Translating the users 'real needs' requires an in-depth understanding of the 'users mental model', the constraints that they face in doing their work, the 'real goal', the core aspects that cause them the most pain. Unfortunately, to do this effectively you need to have the vocabulary that the user has. The development team must use and think with the vocabulary/language of the user. Once we start looking at the language, this invariably leads us into its closely associated ally -- 'the culture'. Language and Culture are very closely related, almost to the point where in practical terms they are inseparable.
Good software can only be build by a team that speaks the customers language and lives (or appreciates) the cultural context that the user lives in.
3. Software systems once built live in a certain infrastructure, here they tend to grow and are adapted over time, i.e. they evolve in an environment. The more components that a software system has to interact with, the more risk we need to watch out for. The sooner the information about this infrastructure and interactions is known, the better it is for the project. For example, could you build a house within out knowing something about the location? Will it be in a rain forest? In a city? On a noisy street? All of these aspects have a bearing on structure of the problem as well as the solution. As such, they determine the overall constraints that one must be aware of to solve the problem.
In a mathematical sense .. we have a problem which is like this - "Given X = 3, What is X*2?". If we did not know the value of X?, we cannot solve the problem. When building a software system -- there are a number of variables that need to have values associated with them before we have a chance of solving the problem. If the value of these variables is NOT know -- early phases of the development effort would have to be in ensuring that we do have answers for it.
Good software can only be build by a team that is aware of all the constraints that have to worth within. The earlier this information is provided, the lower the risk. Early phases of the software development effort should focus on minimizing (eliminating) these risks.
4. An interactive system cannot be properly specified in a static document. We can create static models with the time component (e.g. a Dynamic UML model). Unfortunately, most users are not trained in reading UML, just like most people would not be able to properly read an architects blue prints for a house. Further, these models are very limited because they do not incorporate or capture the 'actual/real' feedback that takes place between users and the software. It is possible to explain a game like 'Quake' with models and words? Does it really communicate to the users? How do we communicate "coolness factor"?
If we cannot properly communicate the intention of the development team, how can the client provide feedback that is of value? The only viable and practical approach is via prototypes that communicate the key aspects and ensure that the very interactions can be communicated. The downside of the prototype is that it often tends to limit the clients mind to the way the problem has been solved -- rather than put forward various options available. Given sufficient budget, we can build multiple prototypes each highlighting different interaction models. The risk is reduced, but it still exists and it is important that we acknowledge it.
Good software can only be build by a team that communicates the interaction models via a usable prototype. They would also be aware of the inherent limitation that the prototype lives in a temporary space and is not a true reflection of the correct/final solution.
5. Software is built to reduce or eliminate pain points (of the various users). There is a certain goal state which will remove the pain. In semi mathematical terms - "Given constraints X, Y and Z. Search and find a path that will remove/reduce pain point P". The path is the final solution. Very closely associated with this aspect is the fact that most users spent a large part of their time retrieving information, i.e. they use computer systems to find information rather than put information into the system. 80% of the interactions with a system would be to get information out, rather than put information in.
Further, the best way to move forward is by ensuring we have a good understanding of the various types of information that the users would want out of the system. If this is available, the actual inputs for the most part can be derived by inference.
Good software can only be build by a team that understands the global pattern of data input and output in the system. Is the system being built to capture information? Does it provide a bunch of reports? But, the critical issue is of course -- can the team trace every input and output back to a pain point?
4 comments:
It's funny that I read this post now. I just started reading Alan Coopers book The Inmates Are unning The Assylum. He argues strongly that interaction design should come before anything else.
It's true that a user won't know what to ask for, but without input from the user, and finding out what goal it is that they wish to achieve, then how can you design a software solution to solve the problem.
At the end of the day, isn't software something that somebody else is going to have to use? So shouldn't that person be involved from the start?
Users should most certainly be involved. The only aspect to be careful with is that most users are not necessarily trained to frame problems, let alone solve them.
A good development team should provide this skill -- ensuring that the correct goal is identified, framed in a way that allows it to be solved.
Ultimately, the users have to be involved quite closely to ensure that the development team has the feedback to stay focused.
One way to fish for good requirements is to observe users. You need to watch their behaviour, then work out how you can solve their problem. For example, if someone is working thru a set of screens and they keep jotting down key info on a piece of paper or post it note - you know that the system is not supporting their work flow.
There are many different ways to get user input into requirements/design, some of which involve users actively designing the interface and suggesting solutions (e.g. participatory design). But much of what i teach in usability is about studying the context and work that users do and using that information to come up with a design solution.
I agree with the idea that "a user wont know..." it can be very difficult for a user to explicitly predict what they might need in the future. Some usability people even recommend against this type of question (ie "do you think this "feature" would be easy to use/useful..") the only way to really know is to test it with a prototype.
You need to _know_ your client and how he thinks.
You can't just take his words for granted and create an elaborate requirements system.
I stronly believe that there needs to be some sort of personal connection with the client. A cold, detached (so-called professional) relationship doesn't work well in developing software, but unfortunately seems part of our work culture ... and an unhealthy one at that.
Post a Comment