Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Detailed Requirements and Functional Requirements
Previous Previous
 
Next Next
New Post 3/26/2010 8:33 PM
User is offline Liro
2 posts
No Ranking


Detailed Requirements and Functional Requirements 

New to this our vendor was supplied with our HLR, then they sent us the Functional Requirements- Do we create our Detailed Requirements from this?  What is the difference between Detailed Requirements and Functional Requirements.  Please help!

 
New Post 3/27/2010 4:08 AM
User is offline Guy Beauchamp
257 posts
www.smart-ba.com
5th Level Poster




Re: Detailed Requirements and Functional Requirements 

 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):

question

answer

what factors caused this project to come in to being?

Driver analysis

how will you know the project has been sucessful?

smart Objectives

how big is the solution?

scope

what applications and technologies will the solution impact

scope

what data will be migrated?

scope

where will it be able to do it?

scope

where will the solution impact?

scope

who is impacted by the solution?

scope

What changes will the project make that will deliver the objectives? 

high level functional requirements

what processes does the solution cover?

scope & high level functional requirements

what will the solution be able to do?

high level functional requirements

what is the process sequence of the solution?

process models

who is involved with each process

process models & process non-functional

what are the rules that each process executes?

process logic

what data does each process need to be able to execute?

process logic

how fast will each process be?

process non-functional

how many transactions must each be able to perform?

process non-functional

where will each process be used?

process non-functional

who is allowed to use each process?

process non-functional

how are all the different sets of data related to each other?

data model

what needs to be known about each set of data?

data attributes

how long will data be kept?

data non-functional

how much data will be kept?

data non-functional

who can access what data?

data non-functional

how big is the project?

project scope

what applications and technologies will the project need?

project scope

who needs to be involved in the project?

project scope

how long has the project got/money?                                              

Hope some of the above helps.

Guy

 
New Post 3/30/2010 2:28 PM
User is offline Liro
2 posts
No Ranking


Re: Detailed Requirements and Functional Requirements 
Modified By Liro  on 3/30/2010 7:44:23 PM)

Thanks for your answer Guy. This does help but I am still unclear. We created our High Level Requirements, then the vendor provided us with the User Functional Requirements. Now we have to create detailed requirements in my mind I am thinking the Detailed Requirements are created from the User Functional requirements that tell us from the vendor how the system will operate.By the way I am creating a Business Rules Catalog that is kept separate from our Wrkbook.  I think the detailed  Requirements template in the workbook should follow this format I am thinking that the Detailed Requirements should actually state how we want the system to work am I wrong in that?  or is this format ok ?:

Who (user role)
What (goal) 
Why (reason)
         gives clarity as to why a feature is useful
         can influence how a feature should function
         can give you ideas for other useful features
that support the user's goals

 

 Do you agree with this assessment if not can you give me an example of what you would use?? Thanks!
 
New Post 3/30/2010 11:31 PM
User is offline Guy Beauchamp
257 posts
www.smart-ba.com
5th Level Poster




Re: Detailed Requirements and Functional Requirements 

 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

 
New Post 4/6/2010 9:30 AM
User is offline Anthony Chen
63 posts
8th Level Poster


Re: Detailed Requirements and Functional Requirements 

 Liro155 wrote

New to this our vendor was supplied with our HLR, then they sent us the Functional Requirements- Do we create our Detailed Requirements from this?  What is the difference between Detailed Requirements and Functional Requirements.  Please help!

 

The terminology here is really just debating semantics.  I just wrote a blog post on the subject here 

http://requirements.seilevel.com/blog/2010/04/what-vs-how-brd-vs-user-requirements-vs-functional-requirements.html

Ultimately the idea is that people call many different types of things functional requirements and requirements exist on a continuum of cascading detail. At the highest level your executives may have a requirement to improve sales efficiency and forecasting. At the lowest level you might have a screen shot and data fields in the actual system.

For any project you need to understand the measurable business objectives because those will drive all of the features. With an off the shelf solution, executives may have decided to do almost no customization. This means business stakeholders will need to change their business processes. On the other hand management may not want to change business processes and so significant customization may be required.

We use a models based approach to describe the type of information you need to collect.  Our approach is called People, Systems Data (PSD). Here is another blog post. If you dig around our blog we have a lot of articles on requirements models

http://requirements.seilevel.com/blog/2006/03/people-systems-and-data-analysis.html

The net of it is that we look at the people who are using the system and what they need to do their job. The other systems in the ecosystem that the new system will need to interact with and the Data the system will be processing. The starting models are an org chart -who are all the stakeholders, system context diagram - map of all the systems, and business data diagram - map of the data from a business point of view and the relationships of data.

From there we do process flows, use cases, data dictionaries etc.

A list of features is not sufficient because the devil is in the details. At the simplest we create process flows and then map screens to those process flows to generate conference room pilots. This allows us to be reasonably sure that all user processes are covered by a screen and that the screens have all the data users need.

 

 

 

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Detailed Requirements and Functional Requirements

Community Blog - Latest Posts

The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, ...
So you’ve found the perfect time and place to study and you’re ready to finally get some work done. You’ve pulled out your laptop, your textbook, and your notes, and four different highlighters. After five minutes of reading your textbook, you start zoning out and thinking about puppies. Then, you go on Tumblr and look at cut...
Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified. 1. Not understanding underlying business need Organization’s business environment keeps changing with respect to Customer...

 






 

Copyright 2006-2021 by Modern Analyst Media LLC