Company logo of Crocus Information LtdCrocus Information Ltd

Business Requirements Analysis consultancy to blue chip companies

Briefing Study: Requirements Analysis and Specification (slide 2)

rass, supplier designs and builds, s2 - intro

this briefing study's slide map | previous | next

Study Introduction

The stages of the software lifecycle addressed by the techniques we'll cover, are from the very start of a project, through to handover of a specification of requirements to a supplier. This includes the optional stage where a feasibility study is carried out before the project proper commences.

We don't focus on interaction with project management, leaving that to another briefing study.

We'll see that a Feasibility Study is a precursor to a full study, essentially bringing together an agreed view of the current environment together with the broad requirements of the stakeholders. It delivers a series of business and technical options from which the stakeholders can choose. It must also be borne in mind that the stakeholders may choose a do-nothing option if the cost benefit analyses and the strategic direction of the business informs it so.

Although the software lifecycle extends far beyond a business requirement specification, where a supplier is doing the logical design, physical design, build, code and internal test, we must be careful not to stray into their area of solutioning.

Of course, the business analyst may need to be on hand during such phases to ensure that requirements are correctly interpreted. The BA may also be needed to help the supplier interact with the business during their stages of logical and physical design.

The production of the document that is handed over to the supplier is largely an exercise in assembling the investigation results. Not all the deliverables produced during the requirement analysis and specification stages will go into the end document as is - there may be some elements it is judged prudent to keep private. Risk analyses, strategic, political or competitor assessments driving the requirements, for example.


Go to Top
exercises on modelling process and data

Related

The 16 Golden rules of a Business Analyst

  1. First and foremost I recognise that my client is the business
  2. I will be a bridge and interpreter between the business and solution providers
  3. I will use my powers of diplomacy to anticipate and prevent obstacles arising
  4. I will document requirements in solution-independent language
  5. I recognise that business doesn't stand still, change is inevitable
  6. I recognise that perfection is the enemy of the good enough
  7. I will clearly document risks, likelihoods and impacts, escalating where needed
  8. I will ensure that the meek are heard as they too have their contribution to make
  9. I will manage everyone's expectations - internal and external suppliers included
  10. I will represent the client, professionally, diligently and with respect
  11. I will listen, mediate, facilitate and encourage
  12. I will treat everyone equally and with respect, regardless of age, religion, seniority or gender
  13. I will never appear rushed or flummoxed
  14. I will always dress appropriately to the gravitas I must bring to the piece
  15. I will reach to one level of detail beyond what is needed to ensure I have captured everything relevant
  16. I won't forget my sense of humour

As a permanent reminder, buy one of our office accessories with the golden rules from our HightonRidley brand store.