0

Large organisations often ousource software projects. For this purpose they create tender documents, which are used by software companies to make a bid.

Tender documents must specify requirements so that interested companies can estimate the effort needed. What is the best format for these requirements ? Use cases, user stories, traditional functional requirements, high level features ?

If you write detailed uses cases, you will need a lot of work up-front, and you have the risk of missing details that will be charged additionally once they are found by the contractor.

If you write high level features, the estimates done by the software companies will not be accurate, and you have the risk the company will underestimate a complicated software project.

What are your thoughts and experiences on this issue ?

Thank you in advance.

2

For a tender, looking at it from an external perspective, I would see a complete Feature List as the center. It represents your black box perspective on the system. It can easily be accompanied (as necessary) by:

  • A (potentially incomplete) set of Use Cases which refer to features. They have a nice visualisation potential and perspective and provicde indications for the system's environment and intended use.
  • A (potentially incomplete) set of Functional and Non-Functional Requirements "beyond" (below) the Feature List. They can specify some essential details for the system.
  • Scribbles, sketches, drawings. They provide insights regarding the expected complexity of user interfaces, dimensions, and the like.
  • Potentially all of the above also for subsystems where it is necessary.
  • A list of relevant Norms and Standards
    • The organisation's standard rquirements for such a product / service
    • Required maturity model
    • Required development, execution, operation, cooperation approach / details
    • Safety / security / social / environmental standards

Authoring these documents can follow the general Requirements Management rules. If you arrange and link the required artefacts properly, change management and impact analysis will be straight forward. (If you're not going to disclose all you have for the tender, it's not a bad thing that you already looked a bit further.)

I would strongly recommend against mixing requirement levels, granularity and type. Although the supplier would have to tidy this up, maintenance on the customer side will become error prone.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.