Chapter 1: Scoping your project
In this chapter, you’ll learn more about scoping your project and gathering requirements. If project scope and requirements gathering feel old hat to you, feel free to skip ahead to chapter 3 and learn more about JavaScript frameworks in the field. If you’re not as familiar and are interested in smoothing out your project development process, studying scope and strategy is probably a great thing.
Scope is generally the way you lay out how large your project is going to be. Scope encompasses the features that are required, the audience you're targeting (and how you plan to acquire them), and generally scopes have some sort of timeframe attached them.
As an exercise, throughout this chapter, I’ll walk-through scoping an example project, in this case an application to let members of a real estate team keep track of their various properties.
Case Study
The team at Realtors & Co. is a small but growing firm of realtors, showing properties in the Anycity metropolitan area. Their website is a little outdated, but more importantly, so are their realtor tools.
They have new realtors coming to the firm who are frustrated that they can’t access valuable deal information from mobile devices (of which they have a variety of platforms and can’t agree on a company phone, so native is out). They hope that building a fresh system will alleviate these pain points, helping them find information faster and easier and then providing better service to their clients.
Requirements gathering
Forming a deep understanding of what you want to do is essential to making defining your scope (and ultimately your framework decision). The first step in the software process that addresses this need is what’s known as the requirements analysis process, sometimes also called requirements engineering.
Interviewing Stakeholders
The basic idea of requirements analysis is to talk to “stakeholders,” find out what they want, and then see if you can see any missing requirements that might arise. Stakeholders can include the commissioners of your app, your future users (especially if these are not the same), and any parties that will support your app, such as operations or an on-site team. User experience can be part of the requirements gathering process, but requirements gathering also encompasses the needs beyond the end user (such as making plans for how your application will acquire users).
Requirements come in many forms. You may get basic information from a client, like “I need a way to examine latest transactions.” The ‘gathering’ work happens when you say, “When you want to look those transactions, how many are you expecting to see at once? What kind of filtering or search capability are you interested in?” you can find out lots of information with questions like these. This process is the opportunity to ask questions and get clarification about anything that could be mistakenly “assumed” down the line.
Even from setting the stage with Realtors & Co., we can identify a couple basic requirement components already.
Viewing property
Making sure the externally-facing listing for the property is up to date and easily found. External listings should be SEO optimized.
Viewing offers
An interface to view offers by date, status, and amount to make it easy to keep clients up to date with their offers status.
We can also identify some technical features we’d like.
Mobile access
Since our realtors are always on the go, mobile access is very important to them. They also don’t want to see a huge drop of information from the desktop to mobile.
Beware of images
Realty is an image heavy business, so that’s something to be aware of. You should build a smart loading solution into the app to keep it fast.
These are just a few examples, you come up with many more during the interview process.
The requirements process doesn’t end after one meeting or document, and that may be the secret of “successful” requirements gathering – embrace an iterative process, and roadblocks (compliance regulation! management-demanded feature!) feel less daunting.
Learning from MVP strategy – Find your features
Lean methodology promotes the concept of an MVP (source), or minimum viable product. An MVP is the absolute minimum you can get away with putting out into the world. The theory of MVP products is to produce something showable/demo-able/basis for interviewing customers in order to see how it performs in the real world before you invest in extensive features you aren’t sure that you need, and to find out if the product is needed at all. The true meaning of MVP can be putting out a video or “Wizard of Oz” type product (someone behind the curtain making it work before the code is written). It’s about finding the answer to the question “will people use this?” and “what do they need?”
In the context of scoping your project, you want to cultivate the spirit of the MVP, if not the letter of the law. If you’re planning your engineering process, you should have already gone through this process of knowing what you want to build (or it’s more moot if you’re building for a client). Now you’re finding the minimum features to have a working public/audience-facing product. When you’ve completed your first round of requirements gathering, that’s the exact time you get to start cutting away at it to get that shorter list of “must have” features.
Top targets for cutting away include things that you expect to be more complicated than you think, things that can be foisted onto another service, and things that kind of constitute the “veneer” or the “nice to haves.” If you can justify “we’ll do that in the next iteration!” then chances are that you should.
For Realtors & Co., there are a few sample targets that you could cut away at:
- Image loading requirements - can we shove this off onto a service or plugin to do the work at a minimum level?
- User permissions – we have internal and external views, edit views, and as such that can easily get complicated. Luckily, there are plenty of established libraries to get a basic authentication/permissions system off the ground.
Components of your scope (what not to miss)
With your initial requirements, here’re some categories to make sure you’ve covered them.
Server-side and Operations
When you’re scoping your project and know you’re doing some heavy JavaScript lifting, don’t forget about your good friend The Server. Server-side support is absolutely key, and you will make yourself and your operations (ops) team much happier by keeping it in mind throughout the development process. In particular, you should think about what kind of API backing you’ll (most likely) need. This comes into play when you’re finalizing your client-side framework, as some frameworks work better with certain backends.
For example, Django is great for building quick and easy APIs to interface of the database, but there is some configuration to do if you want to use say, Backbone, which works pretty well with out-of-the-box Rails APIs (and there’s even a site dedicated to Backbone with Rails tutorials), and makes even more sense to pair the two when you combine Rails + Backbone + CoffeeScript – you’re starting to write in the same sort of dialect from the frontend to the backend.
Depending on how you’re getting your data, there’s a good chance you don’t need backend frameworks as large as Django or Rails. Flask or Sinatra can (and do, for many applications) back strong APIs. It all depends on how much server-side processing your application needs to service the client-side; it can range from very little (small API framework) to a lot (Java backend to handle proprietary algorithms).
Realtors & Co. Operations Assessment
Hosting is outsourced to a managed hosting company at Realtors & Co., so anything they use is informed by if their host supports it. Luckily, their host is flexible, supporting PHP, Python, and Ruby on a Linux stack; other configurations are not supported by customer service.
Data
Your data is another (extremely) important exploration. What kind of data will you have? What are you storing? How much of it will there be? These are the kinds of questions you need to be considering during requirements gathering. The answers will form your choice of database (or not) and help you consider how to model your data through the back and frontend of your application.
Depending on how you’re going to store data, or what kind of data you need to store, you’ll decide how to design your API or other interface (but generally with your good buddy The Server) to interact from the client-side to the server-side.
For Realtors & Co., they’ll be storing some public and private data. A realtor should be able to see the offers and prices of a property, and if those have changed over time (they agreed that the most recent change is a fine view to start with).
The firm is growing, but currently only in one metropolitan area, and there aren’t plans to expand beyond that area yet, and they have about 40-60 properties on the market at a time.
Time & Team
Don’t forget time and team limitations. If you have three months and three people, you’ll probably make a different decision from someone with six months and 25 people. With time and team, you also have to consider literacy rate, or the rate at which your team will get up to speed with whatever framework your choosing. If it’s new to many of the members of the team, tack on some time to your ballpark estimate.
Realtors & Co. has an in-house web development team completing the project. They’re 8 people strong (1 manager, 7 engineers with a range of front and backend experience). Technical support is outsourced.
The Dreaded Time Estimation
Time estimation in software projects is so complicated that you can read academic articles about the subject and the topic is still being studied today. However, chances are extremely good that you’ll need to have at least some “ballpark” number.
There’re plenty of formulas for making an estimation, such as previous velocity, so if you have one you like, stick with it. I personally go with the “Scotty principle” (after Montgomery Scott in Star Trek, and his very interesting estimations for engineering completion time). Basically, I take what I’m pretty sure I can accomplish (which is a very ambitious number), and then double it, or some would say add 25-50%. The more unknowns you have, the more padding you should add.
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.