• Home
        • Team as a Service

          Under Attrecto’s Team as a Service offering, clients get quick access to a cohesive team of cross-platform developers, UI/UX designers, QA professionals and support engineers

          LEARN MORE

        • Project Based Development

          Developing user-friendly and intuitive apps and web interfaces that are truly enjoyed by people for their quality, look, feel, colors and functionality – not just merely “used.”

          LEARN MORE

        • Pre-Development Planning

          Get a comprehensive technology and/or UX/CX review on your project through our pre-development workshop. Business value in just 48 hrs with a Deloitte fast 50 company!

          LEARN MORE

  • Who we are
  • Career
  • References
  • Contact
  • Blog
Picture of Attrecto team

Attrecto team

Business Requirements in Software Development

When a client contacts a developer about a software development project, they either have a very clear idea of exactly what they want or just a vague idea of what they want to achieve.

Either way, it’s vital to define the scope of the project before starting work so both parties understand the deliverables and timescales at each stage of the project.

At Attrecto, we’ve developed a short template for clients to fill out when they first contact us about a project. This helps to guide the client through the decision-making process and answers some important business-related questions before we even start thinking about software solutions.

Download your free guide for development process in UX driven projects 


Creating a Value Statement

Many clients aren’t concerned with the specific features and functionality of software at this stage. It’s more important for them to nail down the business requirements that should be based on their vision or goals for the project.


One value statement may not cover the needs to be addressed and the business solution for every customer the client wants to serve. If this is the case, they should develop a value statement to target each group of customers. The final set of value statements will describe the functionality and business solution that are required to meet the needs of all users.


Developing the Value Statement into a Business Outcome Hypothesis

The value statement should capture the major goals and functional requirements of the project, but we then go into more detail by using it to create a business outcome hypothesis. This hypothesis has several important functions:

  • It states the quantitative and qualitative benefits that the business can expect if the hypothesis is proven to be correct. These benefits may be in terms of users affected, the expected impact on processes, products, services and costs, sales, revenues, etc.
  • It defines leading indicators that can be used to help predict the eventual business outcomes. Some examples of leading indicators include the number of users, subscriptions, costs per user, etc.
  • It determines nonfunctional requirements, which are features of the software solution not related to its functionality, such as which architecture and infrastructure it uses, how the software is built and updated, network usage and bandwidth, performance, availability, security, backup, stability, capacity, regulatory details, usability, interoperability, costs, configuration, documentation etc.

If you’re new to the idea of using hypotheses in software development, the concept is not so different from the hypotheses you were probably asked to develop as part of high school science class. You’d then carry out an experiment to test this hypothesis.

You can think of a hypothesis as a “prediction” or “best guess” of what the project will achieve.

An example of a basic hypothesis for software development might be something like: “We believe we can reduce our support requests by implementing a chatbot that will instantly answer frequently asked questions. We’ll know this is true when the number of support requests is reduced by X amount.

We then test this hypothesis in the leanest and quickest way possible to find out early in the development process if the solution currently in development is fit for purpose.


By using this method to define the scope of the project, we avoid adding unnecessary features or focusing on the features themselves rather than the business outcomes.

Other Information Needed Before Development Starts

Developing a business outcome hypothesis is a key concept in agile software development, and it helps us to make sure we’ve defined the full scope of the project before any work starts.

In addition to this formal process, we also capture and discuss other business-related information with the client that may be necessary or helpful for planning development. This may include:

  • A detailed description of business process steps
  • Definition of user stories and use cases in general
  • User personas (with roles in the system)
  • Minimal viable product features (the must-have features of the final solution)
  • Additional potential features (the nice-to-have features of the final solution)
  • Major milestones and deadlines.

By establishing the groundwork and expected business outcomes of your software development project in the beginning, you won’t just have a more seamless experience. This is how you’ll get the results you want to see. 

Download your free guide for development process in UX driven projects

Share this post