We previously stressed the importance of understanding why something is a requirement. Unfortunately, we can’t just ask “why why why?!” until we reach the end of the chain. This won’t be any more effective for us now than it was when we were in kindergarden. Eventually, our listeners will get frustrated, or worse, defensive.
Understanding why is still our goal – but we have to be smart about our interviews to get this information. In our previous post, we identify interviewing as a key technique for eliciting requirements. Interviewing is the cornerstone of our elicitation techniques – even if we gather the bulk of our information in group meetings, we have to follow-up, clarify and validate with individuals. There’s truth behind the old saw that nothing good is designed by committee.
Before the interview
Failing to plan is planning to fail. OK, stop groaning, I know it’s a cliche. Regardless, the first thing we do when interviewing is identify who we need to speak to, and what we need to speak about. If we’re going to talk to a sales manager, about our sales-support software, we will likely talk about user adoption, business processes, and the organization of the sales team. If we are talking to a sales person (a representative user), we will talk about how they do their job today, and how it could be different with the new software. In both cases, we plan our conversation before we have it.
During the interview
Amplifying your Effectiveness has an article on how to run interviews when gathering requirements. This is a great article, and one I’ve added to my links at del.icio.us (you should too).
Some key takeaways from their article:
- Use “how” and “what” questions to get to “why” answers – avoiding the knee-jerk defensive reaction.
- Use “tell me more” questions to drill down – “What happens next”, “Can you show me”, etc.
- Use open-ended questions. Yes/no questions are good for validating what you’ve learned already – not for learning new information.
- Don’t bias the results. It’s easy for the interviewer to ask leading questions. We need to realize if there is an implicit premise in the way we ask a question, and if that would bias the results. When we’re first starting out, this meta-perspective is almost impossible, but it becomes second nature over time. If we review our results (recording our questions helps too) after the interview.
Cliche though it may be – a book I’ve read at least a dozen times is How to Win Friends and Influence People by Dale Carnegie.
In that book, he helps us understand that people enjoy talking about what they do. He provides tips and suggestions about how to gain contacts, gather information, maintain relationships, and speak publicly. If you haven’t already read it, it’s in my top two “books that make you better” list. so go read it. One thing that will make you laugh is seeing the dated dollar amounts in many of his anecdotes (the book was written in 1936). My copy was published in 1964, and the pages are starting to get that nice yellowing that comes from great writing.
Carnegie stresses, encourages, and provides techniques for talking to people about what’s important to them, which is directly related to gathering requirements from the beneficiaries of a new system (and the users, who should benefit, but might not if we don’t gather the right requirements).
After the interview
Here’s where many good interviewers drop the ball. This is the time to put a little extra effort in managing our relationships. We should always followup with the interviewee, and let her know “how it went”. We should give her an update on status and let her know which of her great insights is being incorporated into the spec. Anecdotal data is fine, we don’t need to create a laundry list – just an affirmation that her needs are being addressed, and that the time she spent in our interview was valuable. If there’s something that is important to this stakeholder that didn’t make the cut – give her a head’s up.
If we get stuck for a good pretense to having the conversation, we can always use communication of the schedule as an excuse.
These follow-up conversations establish a long term relationship that is good for future releases, helps with change management of rolling out the solution, and establishes or firms up our credibility.
Understanding the, “Why,” questions is important for context. Do you suggest tying requirements back to corporate strategies to see whether they align or not? Or in otherwords, establishing traceability from corporate strategy to high-level requirements and then down throughout the rest of the SDLC, where appropriate?
For example, if your company wants to be a low-cost provider for a service or product yet half of the requirements being gathered do not align with this (such as expensive packaging) this sort of traceability could aid with consistency.
Great questions Marcus!
One of the most important facets of developing custom software for a client is aligning that development with corporate strategy. I used to work for Texas Instruments, and they had a model they called OST – objective, strategy, and tactics. All of their initiatives, not just software projects, were validated in that framework.
Using your example, the objective might be “Gain dominant market share”, and the strategy could be “Become low-cost provider” (versus a differentiated product offering, or intellectual-property litigation, or another strategy). Then tactics would map to a new product introduction or a restructuring initiative designed to reduce cost of goods sold.
When thinking about software, this approach puts the project in context, and would be used to validate the high level requirements (or GOALS in a structured requirement approach.
Individual use cases and requirements would then trace from those goals. I wouldn’t suggest capturing the strategy in an RM system, but would encourage validation of the goals against it, and then trace from the goals.
Testing my skills for use case writing at the same time asking solution to the following situation (feedback will be too helpful from professionals)
Use case: BA gather requirement from client
Precondition: 60% of application is already made by some other vendor
Post condition: Application overtook and developed by new vendor.
Normal Flow: 1. BA given option to gather requirement (A1, A2, A3 …..)
2. BA gathered the requirement
Alternative Flow:
Business Rule for the use case:
BR1: No previous documentation (SRS) given to BA
BR2: New vendors are using CMMI level 2
Solution Example A1.1 BA chose to gather requirement
A1.2 Start gathering requirement based on existing User Interface
Want to know what can be the scenarios in the given use case to finish the requirement gathering
Hey Student – thanks for commenting. Very novel way to comment, too!
Instead of trying to answer in the form of alternate flows or extension use cases, I’ll just make some statements.
The fact that the new vendor is CMMI level 2 is likely to be unimportant. Take a look at this series of articles on CMMI levels and RMM levels. CMMI Levels and Requirements Management Maturity.
The fact that part of the app is already written may or may not help with development and testing – it doesn’t help with requirements gathering. You don’t know if what was built is actually what is needed. You need to document the needs – and THEN determine the suitability of existing tools (or existing code, in this case) to meeting those needs. Take a look at Software Requirements for Migration Projects and Three Types of Requirements Gathering to see what I mean.
Hope that helps. Any chance you can phrase your next question in the form of a static class diagram? :)