Business Analysis: What Artifacts Do You Need to Start Development?

Previously we discussed with you what you need to know before successful project kick-off. Now it’s time to figure out what artifacts suit best to put your requirements to developers.

Why Formalize Requirements?

In this article, we are going to talk about the most popular and worldwide accepted ways to formalize software requirements. So let’s first make it clear why is important to keep to the proposed standards. In fact, there are a few really good reasons for that:

1. Don’t miss anything
   The first reason for diving into the world of formalized requirements is that this way the probability that you will miss some important junk of work drops significantly. Standard sections to fill in make sure you ask yourself the right questions and as a result, think about your project under all angles required.
2. Understand each other easily
   Secondly, even if you don’t develop a new app every year, developers actually do. So they get used to a certain format they receive requirements in. It’s like speaking a special language both sides understand well. So going for formalized requirements is always a good choice to improve communication.
3. Save time
   And finally, it’s great that somebody has already thought about the structure and artifacts in software project management you need to develop a good project. So why not enjoy the experience of plenty of professionals instead of wasting your time on inventing something new. Writing formalized requirements simply lets you focus on what is really important.

But don’t think that if you go into formalized you will feel like a slave in a desert. There are plenty of options you can go into. Let’s have a look at the scheme Corporate Education Group created:

As you see, there is plenty of fish in the sea. Let’s get into detail now.

Vision & Scope

The first step of requirements analysis is figuring out what is the general vision of the future app is and what scope of works is planned for the initial and (if you already know it) later phases. Here are the artifacts that will help you with that:

1. Vision & Scope Document
   The standard document, which encompasses not only information about your vision of the future product, but also business goals, limitation and a brief description of the major features planned to be developed.
2. Context Diagram
   An optional part of Vision & Scope Document, which shows, how your app will interact with other systems and users. Allows developers to have a bird’s eye view on the project.
3. Use Case Diagram
   This diagram lets you list all the major use cases of the system — i.e. have a quick draft for all the functionality offered.
4. Business Process Model
   This is an extremely useful artifact for both developers and Product Owner. With its help, you will able to think through the whole functionality of your product, make sure nothing is missed out and easily explain it to anybody involved.

Requirements Specification

As soon as you have Vision & Scope figured out, it’s time to get down to requirements specification. The choice here is much bigger, but don’t worry, you don’t have to use them all. Just follow your feeling and look into what sort of information will really work for your specific case. The list of artifacts here include:

1. Software Requirements Specification
   Very popular, yet not compulsory standard document. It is irreplaceable when working viawaterfall methodology. Agile though doesn’t necessarily have it written. SRS contains both functional and non-functional requirements, business rules as well as a bunch of other artifacts listed below.
2. Use Cases or User Stories
   Both Use Cases and User Stories are used to provide maximum details about every single case and functionality planned in the app. It is them that developers will be looking into. Cases and stories have different notation of requirements, but both are extremely popular.
3. User Profiles or User Personas
   To make sure your product meets your business goals, one should understand well who you are making it for. Write it down in User Profiles or User Personas to make sure both you developers understand target audience well.
4. Workflow Model
   Workflow Model is sort of an advanced version of a Business Model, which shows the use logic of your application with different User Roles applied.
5. Wireframes
   Seeing is believing. No wonder creating prototypes is extremely important for your success. Don’t forget to provide developers with wireframes or design to solve all UI issues.
6. Conceptual Data Model, Logical Data Model, Data Dictionary
   These artifacts are much likely to be created by a Tech Specialist or Architect. It is important to plan all data architecture before the start of development in order to avoid any work needing to be redone at later stages.

As you see, there are quite a number of ways to express your requirements. If you have never done this before, it might take a while, so we’d recommend considering the services of business analyst outsourcing.

Rubyroid Labs provides professional Business Analysts to enhance your business. Contact us and get your free consultation within 24 hours.

Originally published at https://rubyroidlabs.com on February 16, 2017.