How to Make SRS in a Software Engineering Project

Lean and Agile software development evangelists often take the floor at conferences to point out that technical requirements specifications are slowly dying out and being replaced with rapid prototyping that looks more interesting and effective than customer-generated specs most of which are just a set of messy notes making little sense to software developers. While this is true about small development projects built from scratch, putting together a good quality technical requirements specification is a must for robust and complex projects or back-sourced projects that need major overhaul and code refactoring by a different vendor.

Having learned some good lessons from completing numerous customers' requests for proposal and our interactive workshops (where we help customers spec out their project), we've accumulated best practices of creating a project requirements spec that any development provider would literally fall in love with. In this blog we'll provide some tips and hacks to let you draft your specifications efficiently and effortlessly and impress a provider you're going to outsource your software development to.

But first of all, let's talk a little bit about the customer / provider quadrangle.

Requirements

Requirements refer to software product / system functions that need to be developed in order to achieve desired system performance (as described by the customer or Product Owner). As a rule, requirements are based on best practices and user experience pertaining to the use of similar products / applications. For any software developer (vendor), it's a key information that is supposed to guide them through the development process. However, this stage of software project specification has the highest number of collisions, errors and inconsistencies that need to be tackled.

Resources

In software development, resources refer to people (IT talent), devices, inventory, time and money to be invested into the process of turning requirements into the actual features. Resources require precise planning and assessment at the project specification stage. Correct prioritization of features by the customer and resources by the vendor allows for elimination of the missed deadlines and minimization of other project related risks.

Opportunities

In a nutshell, opportunities refer to the actual project capacity that the vendor can ensure during custom project development. Let's say the client wants to engage with Intersog on development of their native mobile application for iOS and Android. We have professional senior developers on staff who can be split in two teams and build two native apps for different app stores. But then we find out the client has a limited budget and can barely afford to pay for 2 natives apps. As such, we suggest that the client better takes advantage of our PhoneGap or Xamarin expertise and goes with a hybrid app development at least for the MVP and faster time to market. The client agrees to use this opportunity and, as a result, gains maximum value for their money. That's just one of the examples of what opportunity means as far as specification development is concerned.

Limitations

All of the barriers standing in the way of your effective project specification development are your limitations! To them belong budget, technology stack, licensing, regulatory bans, system configuration or IT infrastructure, etc.

As we can see, all 4 essential elements are closely intertwined and define the overall project success. Let's scrutinize each element to identify key points to consider when working on your technical requirements specification.

Hire talented developers from LATAM, Canada, and Europe

Requirements gathering and analysis

It's a very important process that aims to show developers what users actually expect from this particular application. We always stress the importance of proper requirements gathering and suggest that our potential clients sign up for our one-on-one workshops (either online or offline) where our PMs and BAs sit together with the project stakeholders on client's side to scrutinize each requirement. Some believe this step is unneeded and we, providers, hold such workshops just to better keep a prospect on the hook. But in reality, our practice shows that clients who don't flesh out and polish their specs are at a much higher risk of having something go wrong at later stages of project development than those who have our (or any professional) assistance with their requirements collection and analysis.

If you are strongly against the idea of bringing in external help for your project requirements gathering, you can definitely do it in-house using the following recommendations:

• If you're building an internal use application, create a stakeholder group comprised of experienced software developers and/or architects and heads of all departments that are going to use the application to be developed. Tell them in detail about the project and how it'll benefit their particular department and ask them to provide feedback about what features they believe should be present in an app. Assign a person to be responsible for requirements gathering, analysis and daily communication with your project stakeholder group. As a result, your project stakeholders will create requirements and your experienced IT specialist will analyze and verify them prior to submitting your spec to would-be vendors.

• If you're building a consumer facing application, a good way to collect initial requirements is to conduct a focus group research and get feedback from end users.

Request our Mobile App Strategy Workbook to spec out your mobile development project effortlessly and quickly!

Technical specification levels

• Business level includes system integrations, product finishing, business process modeling and new functional modules
• User level includes UI and UX design requirements
• Functionality level includes system logic and architecture requirements
• Service level includes app response time, load performance, data security, user access and authentication, etc.
• Technology level includes requirements for software platforms, OS and devices

Technical Specification Parameters

Deadlines, stages of development, responsible people from vendor and customer's sides. In short, it's a mix of formal items that make your document a technical specification. A project specification should always be approved by the customer and agreed upon by the vendor in order to avoid changes to be made when the project is in progress (you won't be able to fully avoid such changes, but you can significantly minimize them this way).

In the best case scenario, your project specification should have the following skeleton:

1. Description of requirements for every single feature to be implemented
2. Description of how the desired functionality will be realized
3. Cost breakdown per each stage of work
4. Total cost of development as per project specification
5. Project development stages and deadlines
6. Key milestone deadlines
7. Special terms and conditions (if any)

Key features of a quality technical requirements specification

• Your spec isn't overloaded with requirements

Frequently, customers overestimate their own budgets and become greedy in terms of features they want to place in a single app. This approach is lame both in terms of spending and business value. As a customer, you should aim to build a long-term relationship with your vendor, so it won't be a problem to order more work when the right time comes. If your budget is pretty much limited, we recommend that you have requirements for the MVP first and then scale your project as your economic conditions change.

Also, overloading a specification with requirements can put you at risk of running into creeping featurism.

• Your specification is realistic and executable

Both your requirements and deadlines should be realistic! That's where you have to listen to your vendor the most, as they know for sure how much time is needed to develop this or that feature. Don't forget that the vendor can help you optimize your development costs by using re-usable components from their internal code libraries (why pay for what's already been developed and future-proofed?).

• Your project specification is detailed

Make sure to include all significant details into your project spec. These details may pertain to your app's use cases or interface. The more your spec delves into details, the easier it'll be for your development provider to complete the job. This is especially true with apps that are meant for specific industries and niches such as healthcare, IoT, insurance or banking. The more details you provide about how business will interact with your app, the better developers will understand your expectations.

Would you like to learn more

about talent solutions

For instance, if you have own formulas and algorithms that need to be embedded into your specification, make sure to include them and their detailed descriptions to the scope.

• Your specification is explicit and precise

Vague wording, unclear requirements and different variants of execution will lead you to nowhere! We came across client specifications describing several ways of how their software can be built. And these clients were sure they'd help us, their development provider, better understand the scope. In reality, such specs only embarrass and irritate developers who don't want anyone, even the clients, to dictate how they should develop software products. Remember that the road to Hell is paved with good intentions!

• Your project specification looks into the future

Well, not exactly the spec, but people behind it. If you're confident that product / business process changes are inevitable over time, do consider them when speccing out your project to avoid overheads afterwards.

• Your project specification isn't bogged down in red tape

Have you ever created a software project specification yourself? If yes, you should remember how difficult it is to avoid a temptation of bogging down in bureaucracy and stuff your document with formal executive summaries, introductory sections, and formal expressions. Some of the specs we receive describe every single item like a Criminal Code article including punitive measures for missed deadlines.

Bureaucratic statements often disguise incomplete understanding of project specification goals and objectives. Vendor's liabilities and project costs are stated in the partnership agreements, so there's no need to move them to the specification!

• Your technical specification reads like a technical specification

It may sound weird, but any software development provider has certainly seen specifications that read like complaint books, novels, contracts, user manuals and guides, or even meeting minutes. Such document makes no sense as no vendor will be able to work with it.

Therefore, it's important for companies looking to outsource their project development to a 3rd party provider (no matter where geography wise) and having no or little expertise in-house to either hire an Outsourcing manager to help spec out the project prior to submitting it to vendors, or engage your prospective vendor into spec development process. This won't cost you much, but will shorten time for a development team to understand your project and how to implement it correctly.

Hire talented developers from LATAM, Canada, and Europe

And here're some more rules of successful project specification development.

• Spec out quickly!

The longer you linger and think over your product features and desired functionality, the higher the chance that your competitor will ship the same product to the market faster and you'll lose your competitive edge. Modern technologies are evolving at a rapid pace, so you have to be quick and swift not to miss out on existing opportunities.

• Let your vendor chip in!

As a customer, you may not be very familiar with technology stacks and limitations, resource planning and tasks estimates. Even if you think you are, it's still better to rely upon your chosen vendor's expertise and best practices, as, at the end of the day, it's them who'll be working on bringing your idea to life.

Budget estimation is actually a collaborative effort between client and vendor. Don't expect any adequate budget estimation from your vendor after submitting your initial specification! Complete budget estimate is only possible after your technical requirements analysis and approval by your vendor's PMs and BAs.

After submitting your initial specification to the vendor and discussing the document thoroughly with the vendor's team, you should get the final project development proposal structured something like this:

To conclude with, storytelling about technical specifications and how to put them together the right way can be endless. Specs are a good generator of Internet memes and jokes. Different experts have different opinions about how to create a good quality spec. Some claim they should adhere to IEEE and ISO standards, while the others stress out specifications per se aren't as important as rapid prototypes.

Our advice is - keep your specification clear and concise yet technical and detailed enough for the vendor's team to quickly plug in the process. Don't focus much on formatting your specification, rather make sure it's easy to read and understand. The rule of thumb here is - contents first, formatting second!

Would you like to learn more

about talent solutions