This is the third part of the book summary of the Software Requirements book.
Who is the Requirements Analyst?
The Requirements Analyst is the individual who has the primary responsibility to gather, analyze, document, and validate the needs of the project stakeholders. The analyst serves as the principal conduit through which requirements flow between the customer community and the software development team.
The Requirements Analyst is a project role, not necessarily a job title.
What are the analyst tasks?
- Define business requirements
- Identify project stakeholders and user classes
- Elicit requirements
- Analyze requirements
- Write requirements specifications
- Model the requirements
- Lead requirements validation
- Facilitate requirements prioritization
- Manage requirements
- Interviewing and questioning
Software Requirements Development
What is a Context Diagram?
It is a kind of diagram that is often included in the vision and scope documents.
A System Context Diagram (SCD) in software engineering and systems engineering is a diagram that represents the Actors outside a system that could interact with that system. This diagram is the highest level view of a system.
What is a data flow diagram?
It is the basic tool of structured analysis.
The DFD provides a way to represent the steps involved in a business process or the operations of a proposed software system.
What is a Dialog Map?
It is a way to model user interfaces.
The heart of requirement engineering is elicitation, the process of identifying the needs and constraints of the various stakeholders for a software system. Requirements elicitation is perhaps the most difficult, most critical, most error-prone, and most communication intensive aspect of software development.
Few tips for Requirements Elicitation:
- Simply ask “why” several times
- Imagine yourself learning the user’s job, or actually do the job under the user’s direction. What tasks would you need to perform?
- Probe around the exceptions
- Rather than simply transcribing what customers say, a creative analyst suggests ideas and alternatives to users during elicitation
- Consider the use of focused elicitation workshops
- Don’t justify doing whatever any customer demands because “The customer is always right”. The customer is not always right. The customer always has a point, though, and the software team must understand and respect that point.
What is a CRUDL matrix?
It is an interesting way to search for missing requirements.
CRUD stands for Create, Read, Update and Delete. A CRUD matrix correlates system actions with data entities to make sure that you know where and how each data item is created, read, updated and deleted. Some people add an L to the matrix to indicate that the data item appears as a List selection.
How do you know when you are done in Requirements Elicitation?
You’ll never be completely done, but the following suggest that you are reaching the point to stop:
- If the users can’t think of any more use cases
- If users repeat issues that they already covered in previous discussions
- If suggested new requirements are out of scopes
- If proposed new requirements are all low priority
Your goal is to make the requirements good enough to let construction proceed at an acceptable level of risk.
What is a use case?
A use case describes a sequence of interactions between a system and an external actor. An actor is a person, another software system or a hardware device that interacts with the system to achieve a useful goal.
Use cases are at the center of the widely used Unified Software Development Process.
The objective of the use-case approach is to describe all tasks that users will need to perform with the system.
The user stories that serve as requirements in Extreme Programming are essentially casual use cases typically written on index cards.
Use cases help analysts and developers understand both the user’s business and the application domain. The use case approach helps with requirements prioritization.
A use case is a collection of related usage scenarios.
A scenario is a specific instance of a use case.
Software developers don’t implement business requirements or use cases. They implement functional requirements, specific bits of system behaviour that allow users to execute use cases and achieve their goals. Use cases describe system behaviour from an actor’s point of view, which omits a lot of details. A developer need many other views to properly design and implement a system.
The translation from the user’s view of the requirements of the developer’s view is one of the many ways the requirements analyst adds value to the project.
The result of requirements development is a documented agreement between customers and developers about the product to be built.
Structured natural language, augmented with graphical models, remains the most practical way for most software projects.
What is the Software Requirements Specification?
The SRS precisely states the functions and capabilities that a software system must provide and the constraints that it must respect. The SRS is the basis for all subsequent project planning, design, and coding, as well as the foundation for system testing and user documentation. It should describe as completely as necessary the system’s behaviours under various conditions. It should not contain design, construction, testing or project management details other than known design and implementation constraints.
Who rely on the Software Requirements Specification?
- Customers, the marketing department and sales staff need to know what product they can expect to be delivered
- Project managers base their estimates of schedule, effort and resources on the product description
- The SRS tells the software development team what to build
- The testing group uses the SRS to develop test plans, cases and procedures
- The SRS tells maintenance and support staff what each part of the product is supposed to do
- Documentation writers base user manuals and help screens on the SRS and the user interface design
- Training personnel use the SRS and user documentation to develop educational materials
- Legal staff ensure that the requirements comply with applicable laws and regulations
- Subcontractors base their work on, and can be legally held to, the SRS
Software Quality Attributes
If you don’t explore the customers’ quality expectations during requirements elicitation, you are just lucky if the product satisfy them. Customers generally don’t present their quality expectations explicitly.
Quality goals must be verifiable otherwise you can’t tell whether you’ve achieved them.
- Clarify and complete the requirements
- Explore design alternatives
- Grow into the ultimate product