Software Engineering
Project Inception: Establishing the Vision
The Vision Document
Captures everything you need to know first about a project or product release. Answers the big questions.
Business Requirements
Vision and Scope “Document”
WHY does the organization need the system – what are the business benefits? Why should customers buy it?
Who are the target users/customers. Who is impacted? Who cares about it?
WHAT are the project’s high-level goals and constraints? What problem does it solve? What features does it provide? What differentiates it from other products?
And for planning: When, roughly, will various features be available in the product?
Business requirements describe a need. The goal of the project is to deliver a solution that satisfies all or part of those needs. That information is summarized in the Vision and Scope Document (or sometimes just called the Vision).
COMP3297: Software Engineering 2
Who?
Stakeholder: person, group or organization that is actively involved in a project, is affected by its development or outcome, or can influence its development or outcome.
Helps make sure you get all the input needed to develop the right solution.
Customer: individual or organization that benefits from a product.
User: actually uses the product – the end users. Clearly the source of user requirements and includes indirect users.
COMP3297: Software Engineering 3
Scope?
Scope defines what the project is and what it is not – what should be part of the project and what should not.
For large projects with multiple staged releases, it identifies the part of the overall product vision that the current project or each release will deliver.
Those scopes may change over time under the influence of constraints on budget, schedule, and quality. If a plan for the current release is included, this can be expected to change even faster.
In comparison, the Vision can be expected to be more stable, but can still change as business objectives evolve.
COMP3297: Software Engineering 4
What should be part of the product?
Scope gives a focus for the specification of requirements – helps us decide whether a stated requirement describes a true requirement.
If some proposed software requirement does not contribute to satisfying the business objective then it should not be there. It is not a true requirement.
Provides a focus for stakeholders and developers throughout the project.
q Basis for decision-making.
q Prevents requirements creep. q Prevents gold-plating.
q Helps us decide if we’re done.
COMP3297: Software Engineering 5
The Document (see sample for COS posted in Moodle)
1. Business Requirements
Value
1.1. Background
1.2. Business Opportunity
1.3. Business Objectives
1.4. Success Metrics
1.5. Vision Statement
1.6. Business Risks
1.7. Business Assumptions and Dependencies
2. Scope and Limitations
2.1. Major Features
2.2. Limitations and Exclusions
3. Stakeholders
3.2 Stakeholder Profiles
4. Delivery and Deployment
4.1. Product Roadmap
3.2. Release Plan Shorter-term
3.3. Deployment Considerations
what is preventing us now?
use to evaluate – early if possible.
…that may affect outcome.
Long-term
Depending on the project, you may not need every section.
COMP3297: Software Engineering
6
Use and Practice
7
For small systems, the document can be informal.
But the goal is still to help achieve common understanding.
Think of it as something you would give to a new member of the team to get them up to speed on the project.
It should not be long. It is not the Requirements Specification and should not describe requirements in detail. It is not a product pitch.
Keep the feature list short so that it can be understood quickly. More than 10 features is too many – consider abstracting them.
Since it will be a summary of information that appears in detail in other documents, be careful not to duplicate.
COMP3297: Software Engineering
Vision Statement
Always write a problem/vision statement as a summary of the purpose of the product.
Needed as a clear point of focus throughout development Often use a keyword template:
For
who
the
that
Unlike
our product
Not mandatory to use the template, but do provide the same information.
COMP3297: Software Engineering 8
Example from COS:
Cafeteria Ordering System
1.5 Vision Statement
For members of HKU who wish to order meals from the student cafeterias or restaurants on-line, the Cafeteria Ordering System is a web and native mobile application that will accept individual or group meal orders, process payments, and trigger delivery of the prepared meals to a designated location on the HKU campus.
Unlike the current manual ordering processes, members who use the Cafeteria Ordering System will not need to go to cafeterias to order or pick-up their meals, which will save them time, allow them to maintain recommended social-distancing, and will increase the food choices available to them.
COMP3297: Software Engineering 9
Feature List – why?
Common to describe functional requirements in the form of user stories or use cases – descriptions of a user interacting with the system to get something of value.
Sometimes, major features – capabilities/characteristics of the product that enable users to achieve what they want – are clear from the user stories or use cases. But the format may make some features difficult to see.
Example: Automated payment authorization embedded in a Make Order use case.
Some features cut across many stories and use cases: Logging is a typical example
If we jump directly to user stories there will often be too many to read if anyone wants a quick, clear idea of what services the system will provide. We keep the feature list short so it can serve that purpose.
COMP3297: Software Engineering 10
Feature List – examples
For the COS
FE-1: Order and pay for meals from the cafeteria menu to be picked up or delivered.
FE-2: Order and pay for meals from local restaurants to be delivered.
FE-3: Maintain meal subscriptions for standing or recurring meal orders, or for daily special meals.
FE-4: Maintain and archive cafeteria menus.
FE-5: View ingredient lists and nutritional information for cafeteria menu items.
FE-6: Provide system access through HKU intranet, mobile devices, and the web
(note: this becomes a constraint related to Operating Environment)
COMP3297: Software Engineering 11
Feature Tree
Organised in logical groups. Limit to 3 levels. Provide a quick view of scope. Notice FE-5 subsumed under Menu Ops:
COMP3297: Software Engineering 12
COMP3297: Software Engineering 13
Create a rough Roadmap for delivery, by Release, of the features identified during requirements elicitation and analysis.
Then we can make a rough plan for developing the next Release, here Release 1, as a series of iterations delivering highest priority features first.
Iteration plan for Release 1:
COMP3297: Software Engineering 14
We’ll see that Scrum helps us organize and perform the iterations, but it doesn’t give any guidance about preparation needed at the beginning of a project, ahead of the first iteration.
Project vision Rough initial planning
Sprint 1
Sprint 2
Deploy
Sprint 3
Deploy
COMP3297: Software Engineering
15
Deploy
Some teams have a “Sprint 0” to complete preparatory work. It is different from regular sprints.
Because such a “Sprint 0” breaks the sprint rules outlined in the Scrum Guide, many teams reject the name.
Inception
In other iterative and incremental frameworks, this stage of a project is called Inception – seems a good name.
Example: the Disciplined Agile hybrid model (for staged releases)
What kind of work is completed in Inception?
Potentially, there is a lot. But keep it short – don’t do Waterfall by trying to specify all requirements in detail.
General goals are to learn enough about the project to determine if it is
feasible and whether you should proceed with it. Then complete any
setup needed to start delivering value in Sprint 1.
COMP3297: Software Engineering 16
Possible work in Inception
Establish the Vision
understand the problem, make sure everyone agrees on its scope; identify stakeholders and their interests. Get agreement about vision; identify, in broad terms, the required features of the product;
Identify any major quality requirements (performance, security, …); make a rough plan for when features will be released and deployed.
Go/NoGo
candidate architecture? should the project proceed?
Prepare for Sprint 1
set up infrastructure, automation, and the development environment; create a Product Backlog, sufficiently refined for Sprint 1 planning.
COMP3297: Software Engineering 17
Summary: Vision and Scope
The Vision records what the project is about and collects together the business requirements
Aligns the various stakeholders’ views of the system
The document also identifies the Scope – the system boundary. That allows you to determine what is within, and what is outside the system you are developing.
Even though we iterate and update this document, it is good to define a Scope early – less work will be wasted
If the Vision is long-term, the scope for this release of the product may only cover part of it – Roadmap vs. Release Plan
Extra benefit: As developers you are also building necessary domain knowledge while you build the Vision
COMP3297: Software Engineering 18