Effective Outsourced Software Development From Business Objectives

Successful outsourced software development needs a set of well-written requirements that help the development team create software that aligns with your vision. A standard practice for most companies is to use their business objectives to define and create actionable plans to meet their goals. In software, these objectives are best translated through the use of Software Requirement Specifications.

Like a blueprint, Software Requirement Specifications (SRS) are set with the intent of leading the software development team into producing software that meets the goals of the client. For outsourced software development, having a clear and well formulated SRS is the backbone to the entire development process.

Business Goals and SRS

When you outsource, you want to want to create the highest quality software possible, as efficiently as possible. Doing so will require an understanding of what the software should do, how the software development should do it, and with what resources.

The SRS defines the needs to be fulfilled and their solutions in terms that software development teams can act upon. For example, a banking company wants to create an application that is fast and secure, offering their customers premium service from their mobile device.

While the goals are valid in a business sense, they don’t offer the software development team the information needed to analyze and create a solution that is compatible with the bank’s current infrastructure. This may lead to a solution that is glitchy, or may not work altogether.

The key to defining the problem using SRS is to be as thorough as possible for analysis. Any ambiguity in defining the problem will jeopardize the effectiveness of the solution and the fundamental steps of software development. To help define the SRS, companies follow the IEEE 830-1998 Standards as a foundation to clearly and accurately define the essential SRS for the software development team.

IEEE 830-1998 Standards

According to IEEE 830-1998 Standards set by the Institute of Electrical and Electronics Engineers, the SRS should address:[1]

  • Functionality: Information on the needs that the software should meet.
  • External Interfaces: Details on all inputs and outputs made by users, hardware, and complimentary software.
  • Performance: Expectations on the speed, response time, availability of the software’s functions.
  • Software System Quality Attributes: Details on the security measures, information correctness, or other maintenance considerations.
  • Design constraints imposed on an implementation: An outline of any standards compliance rules or accounting & auditing procedures.

How to Use SRS

Writing a SRS can be a large undertaking for teams that may not have a lot of experience in technical writing. The best practice is to ask the IT department for their input when writing the SRS, as well as input from other departments that interact with customer needs like marketing or engineering.

To start writing the SRS, it is best to break the process down into two steps: User Requirements and System Requirements:[2]

User Requirements

The User Requirements step defines the goals that the software should achieve to meet the user’s needs. This is more specific to the original business goals set by the client company and best describes how the user interacts with the product and its features. For example, users who are using an application to measure the amount of miles ran should be functional with the use of one hand. The miles ran should display on the home screen for easy access as the application runs in the background, using the mobile device’s GPS.

Keep in mind that users include other systems – software or hardware – that will be connecting to the finished product. It is best to involve the software development team in this process to create clear system requirements from these user requirements.

System Requirements

The System Requirements animates how the user of the software can best achieve their goal. For example, the first page of the application should use API’s provided for social media to login for faster access. This will then take you to the second page where the user can access their history from a database that compiles the information into a readable output.

Writing the System Requirements should be a back-and-forth process between the client and software development team to ensure that the requirements are as specific as possible. All system requirements should be testable and linked to a user requirement. Once the System Requirements are written, the client and software development team can then formulate software solutions using the SRS standards.

Developing Requirements Is a Process

Just like business goals, as consumer expectations and the technological environment start to change overtime, so does the SRS. Changes to the SRS are easier to implement when the software development team uses Agile methodologies, because the methodology involves a series of briefing points for Lean Thinking.

Lean Thinking was largely popularized by Toyota Motor Corporation as a method of refining requirements to refit the essentials to the user’s needs.[3] This creates flexibility within software development to create a product with the user in mind.

Using Business Goals to create actionable software requirements is a time-tested method that has proven to be widely effective. Tiempo development uses Agile methodologies to create cost-effective software by aligning the development process with the client’s vision. For more information about Tiempo Development’s version of a SRS, and the use of Agile methodologies to create high-quality software, read our whitepaper about the Tiempo Quality System.

[1]Gregor B. Requirements Specification with the IEEE 830 Standard DRAFT . University of Ottawa. https://www.site.uottawa.ca/~bochmann/SEG3101/Notes/SEG3101-ch3-2%20-%20Requirements%20documentation%20standards%20-%20IEEE830.ppt.

[2] Lynne G. “Requirements Management in Outsourcing Projects”. Sourcing Magazine. http://www.sourcingmag.com/requirements-management-in-outsourcing-projects/

[3] Jason M. “Agile Requirements Definition and Management”. Scrum Alliance. https://www.scrumalliance.org/community/articles/2012/february/agile-requirements-definition-and-management