Comments on: How To Interview When Gathering Requirements http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/ Software product success. Sat, 19 May 2012 12:04:06 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: Scott Sehlhorst http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/comment-page-1/#comment-165191 Scott Sehlhorst Thu, 18 Oct 2007 01:08:37 +0000 http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/#comment-165191 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. <a href="http://tynerblain.com/blog/2007/01/25/cmmi-and-rmm-intro/" rel="nofollow">CMMI Levels and Requirements Management Maturity</a>. 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 <a href="http://tynerblain.com/blog/2006/03/09/software-requirements-for-migration-projects/" rel="nofollow">Software Requirements for Migration Projects</a> and <a href="http://tynerblain.com/blog/2007/03/26/types-of-requirements-gathering/" rel="nofollow">Three Types of Requirements Gathering</a> to see what I mean. Hope that helps. Any chance you can phrase your next question in the form of a static class diagram? :) 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? :)

]]> By: Student http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/comment-page-1/#comment-162659 Student Fri, 12 Oct 2007 08:20:57 +0000 http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/#comment-162659 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 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

]]> By: Ten Requirements Gathering Techniques « Little K’s Blog http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/comment-page-1/#comment-57199 Ten Requirements Gathering Techniques « Little K’s Blog Thu, 23 Nov 2006 05:13:53 +0000 http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/#comment-57199 [...] Interviews of stakeholders and users are critical to creating the great software. Without understanding the goals and expectations of the users and stakeholders, we are very unlikely to satisfy them. We also have to recognize the perspective of each interviewee, so that we can properly weigh and address their inputs. Like a great reporter, listening is the skill that helps a great analyst to get more value from an interview than an average analyst. [...] [...] Interviews of stakeholders and users are critical to creating the great software. Without understanding the goals and expectations of the users and stakeholders, we are very unlikely to satisfy them. We also have to recognize the perspective of each interviewee, so that we can properly weigh and address their inputs. Like a great reporter, listening is the skill that helps a great analyst to get more value from an interview than an average analyst. [...]

]]> By: Outside reading: Enterprise versus consumer software -Tyner Blain http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/comment-page-1/#comment-239 Outside reading: Enterprise versus consumer software -Tyner Blain Wed, 08 Feb 2006 00:20:44 +0000 http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/#comment-239 [...] This is always a challenge when eliciting requirements too - in an interview with a user, “reliable” and “fast” can be completely ambiguous terms, because they mean different things to different people.   This is why active listening is such a critical skill - it is the best (only?) way to identify when the same words mean different things to different people. [...] [...] This is always a challenge when eliciting requirements too – in an interview with a user, “reliable” and “fast” can be completely ambiguous terms, because they mean different things to different people.   This is why active listening is such a critical skill – it is the best (only?) way to identify when the same words mean different things to different people. [...]

]]> By: Dilbert does product managers -Tyner Blain http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/comment-page-1/#comment-177 Dilbert does product managers -Tyner Blain Tue, 31 Jan 2006 13:22:35 +0000 http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/#comment-177 [...] ObRelatedTopic: How to interview when gathering requirements [...] [...] ObRelatedTopic: How to interview when gathering requirements [...]

]]> By: How to manage data when writing requirements -Tyner Blain http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/comment-page-1/#comment-163 How to manage data when writing requirements -Tyner Blain Sun, 29 Jan 2006 01:09:49 +0000 http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/#comment-163 [...] Kevin knows that there’s a reason why we have a list of citites. He just doesn’t know what it is. So he interviews the stakeholders, and eventually finds out that the marketing department is in charge of the list. Kevin discovers that the list is the fifty cities with the largest estimated number of AOL subscribers. The marketing department has targeted AOL users for this forecasting page. [...] [...] Kevin knows that there’s a reason why we have a list of citites. He just doesn’t know what it is. So he interviews the stakeholders, and eventually finds out that the marketing department is in charge of the list. Kevin discovers that the list is the fifty cities with the largest estimated number of AOL subscribers. The marketing department has targeted AOL users for this forecasting page. [...]

]]> By: Top five ways to be a better listener -Tyner Blain http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/comment-page-1/#comment-159 Top five ways to be a better listener -Tyner Blain Fri, 27 Jan 2006 13:58:03 +0000 http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/#comment-159 [...] Interviewing is the primary requirements gathering process in any project. Getting feedback from users and other stakeholders is important to validating and prioritizing requirements. Communicating with people is critical to success in managing requirements. And listening is at least half of communicating. [...] [...] Interviewing is the primary requirements gathering process in any project. Getting feedback from users and other stakeholders is important to validating and prioritizing requirements. Communicating with people is critical to success in managing requirements. And listening is at least half of communicating. [...]

]]> By: Tyner Blain » Where bugs come from http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/comment-page-1/#comment-127 Tyner Blain » Where bugs come from Sun, 22 Jan 2006 21:22:49 +0000 http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/#comment-127 [...] E1 - The wrong requirements. The first source of errors is stakeholders who don’t describe (or don’t know) what they really want. Or they don’t know why they want it. Everyone who’s gathered requirements has heard things like “Now that I see it working, I realize that what I really want is…” We’ve had the most success in minimizing this situation through rapid-development techniques (repeated iterations of deployment), development of prototypes, and interaction with stakeholders throughout the design process - helping them envision what you are creating before you create it. We won’t succeed by using the spec as a defense: “But we implemented what the spec says” - your clients should not be expected to visualize what a software solution would look like just by reading a spec - that’s your job. [...] [...] E1 – The wrong requirements. The first source of errors is stakeholders who don’t describe (or don’t know) what they really want. Or they don’t know why they want it. Everyone who’s gathered requirements has heard things like “Now that I see it working, I realize that what I really want is…” We’ve had the most success in minimizing this situation through rapid-development techniques (repeated iterations of deployment), development of prototypes, and interaction with stakeholders throughout the design process – helping them envision what you are creating before you create it. We won’t succeed by using the spec as a defense: “But we implemented what the spec says” – your clients should not be expected to visualize what a software solution would look like just by reading a spec – that’s your job. [...]

]]> By: Tyner Blain » Managing requirements conversations http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/comment-page-1/#comment-106 Tyner Blain » Managing requirements conversations Thu, 19 Jan 2006 08:53:14 +0000 http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/#comment-106 [...] As Greg pointed out, we interpret subsets of the specification at a point in time. Writing of the specification also happens piece-meal. Once a portion of the spec has been written, the conversation that occurred starts to immediately lose its relevance. When internal teams are responsible for distilling the inputs from multiple conversations with multiple customers, then conversational models will help the product managers, but only until the spec is written - then the conversation becomes an (infrequent) reference. [...] [...] As Greg pointed out, we interpret subsets of the specification at a point in time. Writing of the specification also happens piece-meal. Once a portion of the spec has been written, the conversation that occurred starts to immediately lose its relevance. When internal teams are responsible for distilling the inputs from multiple conversations with multiple customers, then conversational models will help the product managers, but only until the spec is written – then the conversation becomes an (infrequent) reference. [...]

]]> By: Scott Sehlhorst http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/comment-page-1/#comment-101 Scott Sehlhorst Wed, 18 Jan 2006 04:53:07 +0000 http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/#comment-101 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 <a rel="nofollow" href="http://tynerblain.com/blog/2006/01/04/foundation-series-structured-requirements/">structured requirement</a> 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. 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.

]]> By: Marcus Ting-A-Kee http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/comment-page-1/#comment-97 Marcus Ting-A-Kee Tue, 17 Jan 2006 19:10:35 +0000 http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/#comment-97 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. 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.

]]> By: Tyner Blain » Top five requirements gathering tips http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/comment-page-1/#comment-96 Tyner Blain » Top five requirements gathering tips Mon, 16 Jan 2006 15:09:38 +0000 http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/#comment-96 [...] Interviewing. One on one conversations with stakeholders and users. A key piece of information to get is why. The most important thing to remember when interviewing is to ask open ended questions. When our interviewees tell us what they want, and how they want it (good open ended questions), make sure to capture the information of why they want it. [...] [...] Interviewing. One on one conversations with stakeholders and users. A key piece of information to get is why. The most important thing to remember when interviewing is to ask open ended questions. When our interviewees tell us what they want, and how they want it (good open ended questions), make sure to capture the information of why they want it. [...]

]]>