Hi Liro155,

There are no enforceable rules about what HLR, Functional Requirements or Detailed Requirements are - it depends on how you, your users and your vendor are using the terms.

In my working life I use these terms like this: HLR specify what capabilities the new solution provides. E.g. the ability to record sales. Functional requirements specify the functionality that any computerised part of the solution will provide. E.g. the system will provide the ability to record sales. Note that the HLR in this case made no mention of what was recording sales - it could have been done on an order form for example. The functional requirement on the other hand explicitly states this is what the computerised part of the solution will do. Detailed requirements specify the business rules that must be enforced. E.g. a sale can only be recorded for an existing customer. There are lots of different rules and different ways of documenting them. 

Suggest that you agree with the vendor and the people specifying requirements to you what questions need to be asked and how to record the answers. Typically with a package based solution it is only necessary to specify the Functional Requirements as the detailed rules will be implemented by the package - except for those packages that are configurable in which case you will also need to specify the rules as well for the bits that are configurable.

Here is a full set of all the questions that I ask in a project and places to record the answers (but as mentioned, you need to agree your questions and answer methods with your suppliers of requirements - business users - and suppliers of solution - package vendor):

 Liro155,

As mentioned in the first response, so long as you, your vendor,the people supplying you with requirements and any other stakeholders (people who need to agree with what you propose) agree that what you propose will progress the work, then that is fine.

In my experience it is unusual for a package vendor to ask for detailed requirements unless the package is so configurable that detailed requirements are needed to configure it or they are developing a bespoke solution for you (i.e. it is not a package solution).

The template you propose is not what I would use to define detailed requirements (but like I said, as I am not a stakeholder in your project my opinion is really just hot air). Crucially, it does not answer the one question that detailed requirements should answer: what are the business rules that must be implemented. The template specifies who is trying to achieve what and why. 

The "who" part of that I would normally answer in the scope and process swimlanes.

The "what are they trying to achieve" I would normally answer in the High Level Requirements as outlined in my previous post.

The "why" I would normally answer in the Drivers and SMART Objectives analysis of the project.

The "what are the business rules" I would normally answer in the fully documented process and data models - and these are also known to me as detailed requirements.

There is a linkage between these components that is used to justify every component as you progress down the "chain of reasoning" from Drivers to Objectives to Scope and High Level Requirements to process models to data models. That linkage can be maintained by a CASE tool or manually or (most often) not at all except in peoples' heads and only thought of when challenges are raised. E.g. Currency is defined in the data model as a list of set values, defaulting to GBP (detailed requirement). Why do we need to pick the currency for a sales transaction from a list? Because the process model specifies it (detailed requirement. Why does the process model specify it? Because we need to be able to record sales (high level (and/or functional) requirement). Why do we need to record sales? Because we want to reduce errors in sales order process (Objective). Why do we need to reduce errors in the sales order process? Because omanagement cannot produce reliable management information on the process (Driver).

So that's how I prefer to do it. But so what? Each project is different and demands slightly different ways of working (e.g. the current fad of Agile). What are detailed requirements defined as by you, your vendor and by the other stakeholders in your project? That is what matters. Define and agree that with them and implement that and your job is done.

Bottom line: there is no "one size fits all" for this: you have to define and agree your way of working with all your stakeholders including (in this case) defining how to document detailed requirements.

Guy