Requirements Gathering : Why Context Matters
- Posted by Keith Casey on October 3rd, 2005
- Keith Casey's blog
- Login or register to post comments
In the September/October issue of IEEE Software, I came across an article titled "Why Context Matters" which gets to the difference between functional and non-functional requirements and how the two interact and are interdependent.
Functional requirements are normally taken to be those hard and fast rules like "the speedometer must accurately report speed to the user." Everyone in the industrialized world has a pretty solid idea of what it should do or how it should work. Therefore, there isn't much room to wiggle.
Non-functional requirements are much more "squishy" and open to interpretation of the people capturing the requirements, the users, and those actually implementing the functionality. A rule like "the speedometer must report speed in an easily discernible manner". Wow, now we have lots of room to wiggle, which way do we go?
This is where the Context comes into play.
We need to know how the user expects to interact with the component, how important it is to them, and what the connection is between our system requirements and our business rules. The worst part is that this is an ongoing process. It never ends... even if the customer is sitting next to you slapping your hands when you make a bad decision.
Of course, there are some Project Management methodologies - such as Waterfall - that can do a poor job of this effort while there are others - such as various Agile Methods - that involve the customer early and often in the process. This serves as an outside review of the overall system. By no means should you expect the customer to perform Validation or Verification of the system, but this can catch some of the big glaring oddities in the system prior to release and much earlier in the development cycle.
Communication and a certain amount of understanding of the customer is vital. You need to determine how they're using the existing comparable functionality, why they do it a particular way, and what they expect to happen afterwards. If the customer sees something unexpected, it doesn't matter how fast/efficient/error-free/nifty a system is . By their standards, the system is "wrong" and now you have to "fix" it.
In case you didn't detect the "squishiness" in the initial functional requirement for the speedometer, here are a few variables to play with:
- US company exporting to the EU
- EU company exporting to the US
- The display which must read the same regardless of the viewing angle
- It's for an aircraft
- It's for an golf cart
- It's for an Formula-1 car
It doesn't take much thought to see how any of those scenarios which could radically change the implementation. Our requirements are not complete until we capture this information.
The dedicated hosting server is well-managed server of first-rate to manage all hosting data exclusively. The godaddy offers very cheap domain registration of the clients which is really a good offer for the personal webmasters. For the rapid development of business, there is a need of implementation of unique and advanced ecommerce hosting tools. For this purpose, you may have contract with any reliable website hosting company. The cheapest domain name registration is offered by a lot of hosting service providers. The webhosting net provides all features of hosting for the clients in the most discounted rates, having PHP, ASP, web site development tool, email marketing and FTTP etc.
experience in applied research
In my professional capacity I manage a team of developers to produce software in applied research. In particular we build humanities computing applications where the non-functional requirement may be for enlightenment or aesthetic provocation. Talk about fuzzy requirements!
I plan on writing a few articles on pm-blog about the trials and intrigue of managing research projects, but as a hint of things to come, I've found that those of us from the science and engineering world often have a narrow view of what constitutes a functional requirement. It is sort of like asking a philosopher to make a statement of fact -- they very well may have only a hand full of certainties.
This isn't to say that no effort should be put into clarifying the product spec, but non-functional or fuzzy requirements are interesting topics. Thus far I've managed their complex scope with agile methods to keep putting a prototype or straw man in front of the stake holders. Gradually we have been able to clarify the end goal.
Agile Methods
Personally, I think Agile Methods are the key to most of it.
Think about when you're driving on the highway: you pick a point somewhere in front of you and start driving.
Do you then estimate how long it will take to get there, close your eyes, and hope for the best?
No, driving - no matter how straight the road - is an entire series of course corrections. Most are tiny, but some can be huge. Regardless, a few degrees of course corrections can make a huge difference over time.
Ask "why" before asking "how"
Almost every requirement I receive is "squishy". A lot of times the customer has a deeper requirement than the one they actually state. For this reason, I ask them why this requirement is important to them. This usually reveals a more fundamental requirement.
Of course, I also ask for a real-world use case scenario to get the context. This helps in determining whether there are any potential conflicts and uncovers some potentially major details.
I agree that this is an absolutely fundamental part of requirements gathering. Without it you could spend days, weeks or months developing a feature that never gets used.