Previous posts:
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
What are important skills for an analyst?
- Listening
- Interviewing and questioning
- Analytical
- Facilitation
- Observation
- Writing
- Organizational
- Modeling
- Interpersonal
- Creativity
Developers who enjoy collaborating with customers to understand the needs that drive software development are good candidates to specialize in requirements analysis.
Software Requirements Development
Software Requirements Development
What is the product vision?
The vision describes what the product is about and what it eventually could become. The product vision aligns all the stakeholders in a common direction.
What is the project scope?
The project scope identifies what portion of the ultimate long-term product vision the current project will address. The details of a project's scope are represented by the requirements baseline.
For each vision there are usually multiple project scopes.
What is a Context Diagram?
It is a kind of diagram that is often included in the vision and scope documents.
From Wikipedia:
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
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
There is no formulaic way to write excellent requirements. The best teacher is experience!
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.
- Availability
- Efficiency
- Flexibility
- Integrity
- Interoperability
- Reliability
- Robustness
- Usability
There are other software quality attributes that are usually important for developers:
- Maintainability
- Portability
- Reusability
- Testability
To address the problem of ambiguous and incomplete non-functional requirements, consultant Tom Gilb has developed Planguage, a planning language with a rich set of keywords that permits statements of quality attributes and other project goals.
Certain attributes combinations have inescapable trade-offs. The designer and programmers will have to determine the best way to satisfy each quality attribute and performance requirement.
The following table is extremely useful to understand the positive and negative relationships among quality attributes.
What does it mean prototyping?
Prototyping puts a mock-up or an initial slice of a new system in front of the users to stimulate their thinking and catalyze the requirements dialog.
Prototyping serves three major purposes:
- Clarify and complete the requirements
- Explore design alternatives
- Grow into the ultimate product
What is an horizontal prototype?
Horizontal prototypes primarily depicts a portion of a user interface. It is also called behavioural prototype or a muck-up.
What is a vertical prototype?
A vertical prototype, also known as a structural prototype or proof of concept, implemented a slice of application functionality from the user interface through the technical services layers. It is useful when you are uncertain whether a proposed architectural approach is feasible.
It is important before constructing a prototype, to make an explicit and well-communicated decision as to whether the prototype will be discarded after evaluation or become part of the delivered product. The throwaway prototype is most appropriate when the team faces uncertainty, ambiguity, incompleteness, or vagueness in the requirements.
What is a paper prototype?
It is a cheap,fast and low-tech way to explore what a portion of an implemented system might look like. A similar technique is called storyboard.
The biggest risk of prototyping is that a stakeholder will see a running prototype and conclude that the product is nearly completed.
The next steps in Requirements Development is setting priorities.
Why prioritize requirements?
To make sure the product delivers the most valuable functionality as early as possible.
How to establish priorities?
One way to assess priority is to consider the two dimensions of importance and urgency.
Few software organizations seem to be willing to undertake more formal methodologies like Quality Function Deployment (QFD) or Total Quality Management (TQM).
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.