This is the second part of the following book summary.
Previous posts:
Let's continue our discussion with new questions.
Who is a customer?
An individual or organization who derives either direct or indirect benefit from a product.It is clear that customer development relationship is extremely critical to software project success.
Who is a user?
What? Is not the same as the customer? Well, not necessary!
So, what is the difference between Users and Customers?
Users use your product. Customers buy it.
Your users may be the customers and this is often the case for commercial software development. However, it is important to remember that this is not always true.
From Wikipedia:
Stakeholders are anyone who has an interest in the project. Project stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be affected as a result of project execution or project completion.
All stakeholders share a common objective:
Build a successful software product that provides adequate business value and rewards to all stakeholders
Excellent software products are the result of a well-executed design based on excellent requirements. High-quality requirements result from effective communication and collaboration between developers and customers - a partnership.
A collaborative effort can work only when all parties involved know what they need to be successful and when they understand and respect what their collaborators need to be successful.
What are the rights of software customers?
- Expect analysts to speak your language
- Expect analysts to learn about your business and your objectives for the system
- Expect analysts to structure the information you present during requirements elicitation into a written software requirements specification
- Have analysts explain all work products created from the requirements process
- Expect analysts and developers to treat you with respect and to maintain a collaborative and professional attitude throughout your interactions
- Have analysts and developers provide ideas and alternatives both for your requirements and for implementation of the product
- Describe characteristics of the product that will make it easy and enjoyable to use.
- Be given opportunity to adjust your requirements to permit reuse of existing software components
- Receive good-faith estimates of the costs, impacts, and trade-offs when you request a change in the requirements
- Receive a system that meets your functional and quality needs, to the extent that those needs have been communicated to the developers and agreed upon
What are the duties of software customers?
- Educate analysts and developers about your business and define business jargon. The intent is not to transform analysts into domain expert, but to help them understand your problems and objectives.
- Spend the time that it takes to provide requirements, clarify them, and iteratively flesh them out
- Be specific and precise when providing input about the system's requirements.
- Make timely decisions about requirements when requested to do so
- Respect a developer's assessment of the cost and feasibility of requirements
- In collaboration with the developers, set priorities for functional requirements, system features, or use cases.
- Review requirements documents and evaluate prototypes.
- Communicate changes to the requirements as soon as you know about them.
- Follow the development organization's process for requesting requirements changes.
- Respect the processes the analysts use for requirements engineering.
What is the concept of Signing Off on the requirements document?
Many organizations use it as the make of customer approval of those requirements.
The sign means:
I agree that this document represents our best understanding of the requirements for this project today and that the system described will satisfy our needs. I agree to make future changes in this baseline through he project's defined change process. I realize that approved changes might require us to renegotiate the cost, resource, and schedule commitments for this project.
This definition is extremely important because it contains an important thing. Everyone agree that it's impossible to know all the requirements early in the project and that requirements will undoubtedly change over time. This is why the signing process should never used as a weapon.
The most important thing of the sign-off ritual is the concept of establishing a Baseline of the requirements agreement, a snapshot of it at a point in time.
What software development methodology to use?
The author of the book explicitly say that being a strong supporter of a specific software development methodology is not usually desirable. It is by far, more important to identify and apply industry best practices rather than devising or purchasing a whole-cloth solution.
Even if you do adopt a commercial methodology, adapt it to best suit your needs and augment its components with other effective practices from your tool-kit.
I don't have a strong experience but I have to say that I entirely agree with him. This seems the most pragmatic way to approach the problem.
So, what are good practices for Requirements Engineering?
- Train requirements analysts
- Educate user representatives and managers about requirements
- Train developers in application domain concepts
- Create a project glossary
- Document the steps your organization follows to elicit, analyse, specify and validate requirements.
Let me remember the typical steps of requirements engineering:
- Requirements Development
- Requirements Elicitation
- Requirements Analysis
- Requirements Specification
- Requirements Validation
- Requirements Management
Let's see what are the good practices for each type of requirements engineering.
What are good practices for Requirements Elicitation?
- Write a vision and scope document
- Identify user classes and their characteristics
- Select a product champion for each user class
- Establish focus groups of typical users
- Work with user representatives to identify use cases
- Identify system events and responses
- Hold facilitated elicitation workshops
- Observe users performing their jobs
- Draw a context diagram
- Create user interfaces and technical prototypes
- Analyse requirement feasibility
- Prioritize the requirements
- Model the requirements
- Create a data dictionary
- Allocate requirements to subsystems
- Apply quality function deployment
What are good practices for Requirements Specification?
- Adopt an SRS template
- Identify sources of requirements
- Uniquely label each requirement
- Record business rules
- Specify quality attributes
Remember that the goal is to develop requirements of sufficient quality and detail that managers can construct realistic project estimates and technical staff can proceed with design, construction, and testing.
- Inspect requirements documents
- Test the requirements
- Define acceptance criteria
- Define a requirements change-control process
- Establish a Change Control Board (CCB)
- Perform requirements-change impact analysis
- Establish a baseline and control versions of requirements documents
- Maintain a history of requirements changes
- Track the status of each requirement
- Measure requirements volatility
- Use a requirements management tool
- Create a requirements traceability matrix
- Select an appropriate software development life cycle
- Base project plans on requirements
- Renegotiate project commitments when requirements change
- Document and manage requirements related risks
- Track the effort spent on requirements engineering
- Review lessons learnt regarding requirements on other projects (project retrospectives)
Please, No!
As I already said, you should think of these good practices as new items for your requirements tool-kit. Consider your business and processes and choose the practices that can provide you the most benefits.
You should never forget the 80-20 rule and that the most important thing is to have a continual improvement process.
The website associated with the book contains a lot of templates that can be used as a starting point. Unfortunately, you need to pay for them.
I would like to finish this post with a sentence with effect:
Gathering and validating requirements are among the greatest challenges is software development
No comments:
Post a Comment
What you think about this post? I really appreciate your constructive feedback (positive and negative) and I am looking forward to start a discussion with you on this topic.