The Scope Statement , What you need to know about it , How To Write One
I am new to the software world . but I believe that sharing knowledge is the key to growth
Introduction
Stave McConnell said “You might think that all professional programmers know about the importance of preparation and check that the prerequisites have been satisfied before jumping into construction. Unfortunately, that isn’t so ” , also he said “One of the key ideas in effective programming is that preparation is important. It makes sense that before you start working on a big project, you should plan the project. Big projects require more planning; small projects require less. From a management point of view, planning means determining the amount of time, number of people, and number of computers the project will need” , all the reference for building high quality projects start from understanding the client , if the software doesn’t fulfill the requirements of the client , you are not a good developer because as developers we build solutions and products for clients not for us . for a high quality process of building we need to write a document where we specify what the client needs and what we can do this document is what we call as Scope Statement .
Definition
The Scope statement is a contractual document contains all the details about the project the company need to start building the software , it is the document where we specify in an official way the client requirements , the quality of the building process depend on the Scope statement quality .
for large projects the client who is responsible for writing the scope statement but for medium projects the leader can write this document after having a big knowledge on the project domain . the more you can understand all the details about the project the more you can write a high quality Scope statement . we call this the developer jobs
Writing our First Scope Statement
lets give an example to understand how to write one , we suppose that one of the world’s 50 best restaurants come to our company for build a web app where the restaurants clients can make reservations and discover the restaurants , from here we can start construction the first chapter on our document it is
The Context of the Project
it is the chapter where we can find our client and some details about the client , details about why we need to build the project in this chapter we need to talk about those topics :
1-abstract :the manger of the Frappe restaurant and the leader of devdjuice decide to build a digital solution that satisfied the following requirements : … , for the clients that decide to discover their restaurant or make a reservations .
2-the Company context : the frappe restaurant is restaurant build by alouani youssef in 2030 start by serving his friends and family to become one of the 50 best restaurant in the world
3-challenges and goals : the goals is to make a web app that is able to increase the number of reservations by 200% in the first year .
4-the team : here we present our team members and their roles in the building process
5-Deliverable : the date for the deliver the parts of the product .
6- the provisional schedule : where we make a prediction for the process or the life cycle of our software in our team
after this we can go for the next step
Benchmark
this part is so important for our project .it is the chapter where we give some analytical numbers and units because we take some time in analyzing our future competitors and their solutions, that helps us to make a good decisions , those decisions based on the statistics and analytical tools
Marketing considerations
this part it is so important because here we can try to understand the users of our product, our software .We can know and collect details about them , their ages , psychologies , their salary , their interesting , their languages and other informations , in this chapter we create what we call the persona of our product
Graphical Conception
in this part we go for our graphical choice based on the last chapter , we choose the colors ,the logo and the images to use and more …
The user interface is often specified at requirements time. If it isn’t, it should be specified in the software architecture. The architecture should specify major elements of Web page formats, GUIs, command line interfaces, and so on. Careful architecture of the user interface makes the difference between a well-liked program and one that’s never used.
Functional Requirements
this chapter contain all the functional details , what the software have to do , in our case for example we need to make sure that our web app can provide the following functions :
1- a Reservation System : where visitors can make reservations
2- a back-office for the restaurants administrations : where the restaurants administrations can makes changes based on the restaurant situation and offers and sessions .
3- front-office multi-lang : an app in multiple languages to make it easy to use by multiple type of visitors with different languages like french, English and spinach , Chinese . Based on the marketing considerations chapter .
those requirements should be with more details to ensure that our software do what it need to do in other word what our client expect exactly to do .
also in this part we need to add the first prototype for our interfaces .
technical Requirements
this chapter is for the justifications of the technical tools , frameworks , programming languages . To ensure the client that we make the best technical choice that is compatible with the functional requirements of the project .
Budget
the last chapter where we make sure that you give details on the budget ,the price of each step in the process , the life-cycle , based on the project requirements ‘ functional requirements and the time needed for the building’
Some Advice
the key for a high quality project is in the client satisfaction , the differentiation of your solutions .
You need to understand deeply that the client doesn’t have a stable requirements and you have to be ready for this we call this The Myth of Stable Requirements
Also to make sure that you can give good answers for those questions :
Specific Functional Requirements
❑ Are all the inputs to the system specified, including their source, accuracy, range of values, and frequency?
❑ Are all the outputs from the system specified, including their destination,
accuracy, range of values, frequency, and format?
❑ Are all output formats specified for Web pages, reports, and so on?
❑ Are all the external hardware and software interfaces specified?
❑ Are all the external communication interfaces specified, including hand-
shaking, error-checking, and communication protocols?
❑ Are all the tasks the user wants to perform specified?
❑ Is the data used in each task and the data resulting from each task specified?
Specific Nonfunctional (Quality) Requirements
❑ Is the expected response time, from the user’s point of view, specified for all necessary operations?
❑ Are other timing considerations specified, such as processing time, data transfer rate, and system throughput?
❑ Is the level of security specified?
❑ Is the reliability specified, including the consequences of software failure,
the vital information that needs to be protected from failure, and the strategy for error detection and recovery?
❑ Are minimum machine memory and free disk space specified?
❑ Is the maintainability of the system specified, including its ability to adapt
to changes in specific functionality, changes in the operating environment,
and changes in its interfaces with other software?
❑ Is the definition of success included? Of failure?
Requirements Quality
❑ Are the requirements written in the user’s language? Do the users think so?
❑ Does each requirement avoid conflicts with other requirements?
❑ Are acceptable tradeoffs between competing attributes specified — for
example, between robustness and correctness?
❑ Do the requirements avoid specifying the design?
❑ Are the requirements at a fairly consistent level of detail? Should any
requirement be specified in more detail? Should any requirement be specified in less detail?
❑ Are the requirements clear enough to be turned over to an independent
group for construction and still be understood? Do the developers think so?
❑ Is each item relevant to the problem and its solution? Can each item be
traced to its origin in the problem environment?
❑ Is each requirement testable? Will it be possible for independent testing to determine whether each requirement has been satisfied?
❑ Are all possible changes to the requirements specified, including the likelihood of each change?
thanks for reading this ja.
