Previous posts:
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.
Who are the stakeholders?
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.
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?
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.
What software development methodology to use?
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.
So, what are good practices for Requirements Engineering?
Some generic practices are:
- 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.
- Requirements Development
- Requirements Elicitation
- Requirements Analysis
- Requirements Specification
- Requirements Validation
- Requirements Management
- 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
What are good practices for Requirements Analysis?
- 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
- Adopt an SRS template
- Identify sources of requirements
- Uniquely label each requirement
- Record business rules
- Specify quality attributes
What are good practices for Requirements Validation?
- Inspect requirements documents
- Test the requirements
- Define acceptance criteria
What are good practices for Requirements Management?
- 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
What are good practices for Project Management?
- 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)
Should I adopt all the practices?
Please, No!
I would like to finish this post with a sentence with effect: