Any aspiring looking to build a great software product could be forgiven for feeling overwhelmed. A quick Google search turns up a lot of conflicting, dated examples for a product requirements document. People used to follow the and define everything their software would do at the outset (think bloated Use Cases and UML diagrams). We don’t want to waste precious time trying to define every possible thing your software will do and frankly, no one likes writing (or reading) a verbose product requirements document. Today, savvy project managers have shifted to the new, Agile side of the spectrum where the product is released quickly, feedback is obtained and improvements are made iteratively. While I am a big believer in Agile and Scrum, it is not sensible to just hire a development team and start building features without knowing what you are getting into. This article will help you write a product requirements document that will be good enough to get a reasonably accurate estimate from a dev shop. We want to strike the right balance between being prepared and being agile. In other words, the bare minimum effort needed to get started building a great product. What is a Product Requirements Document? A Requirements Document should act as the starting point for your product: outlining its purpose, who will use it, and how to use it. It is an essential precursor to design and development. This article should help you create a requirements document that straddles the line between concise and precise. This article is for entrepreneurs and product owners who are looking to build a digital product. To avoid sounding too vague I have decided to use examples from an e-commerce website, but this could easily apply to creating a mobile app or software program. THE ‘BARE MINIMUM’ FRAMEWORK Often a product owner will have grand ideas for their project and all of the features it might have in the future. Dreaming big is great, but it’s extremely important at the outset to narrow your focus down to the minimum set of features that you need in the first release. This is called the. After you release your product and get feedback from your users, you can then decide what additional features you want to add. But while you are writing your product requirements document, clear your head of all those potential future features and just define those that will be included in the first version of your product. Note: Of course, if there is a future feature that must be known about at the outset, then the development team should know it is coming and I’ll talk about how to include that. Enough preamble, below are the sections I suggest for a simple product requirements document: • Goals • User Personas • User Stories • Sitemap • Page Descriptions • Wireframes (optional) • Non-Functional Requirements • Risks • Future Iterations Goals The business goals and objectives serve as the context, showing the dev team why they are building what they are building. Here are some common questions you can ask yourself when fleshing out this section: • What is the purpose of this project? • What are the problems it will solve? • How will it streamline or improve the current process or facilitate a new process? • What is the product vision? The Product Design Specification document documents and tracks. Any changes to this Requirements Definition will be. Product Design Specification Template. Check out our Free Product Requirements Document for more examples. User Personas User Personas are hypothetical individuals who match your desired, or actual, audience. Thinking about the background of these users will improve your ability to create a product that suits meets their needs. Are one of the areas that people tend to drown in. So let’s establish some rules to keep you afloat. • Cover the primary types of users. You don’t need to create a persona for every kind of user, just enough to illustrate the main groups who will use your product. For simple applications, 3 good profiles will cover more than 80% of your user base, but if your application is complex you may need more. • Focus on what you know. Making up details to simply fill an end user profile is counterproductive. • Start with these 5 metrics. Occupation, age, gender, location, education.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
March 2018
Categories |