3

Does it make sense to say that I elicit business requirements from the end-user community, then take those business requirements to the functional team to create functional requirements, then take those functional requirements to the system engineers and architects to create the system requirements?

For example: business requirement is, user should be able to enter data into a text box. Functional requirement is that the text box can accept user data of 40 characters in length and no more and that the data is passed to a back-end application. System requirement is that the data is accepted and passed using Java to the backend Oracle DB.

Does that work?

2

As a business analyst, I would even say the business requirement in your example could be more of a functional requirement as it talks to a solution not a need. To me a Business requirement is meant to be written from a business perspective and should be technology agnostic as much as possible. Depending on the needs of the business, the need could be met by a text box, a drop down list, a combo box, etc...

1

In the terminology the terminology that I'm used to, your uses for the words don't align. However, there may be alternative definitions in use by other organizations.

In my experience, there are multiple sources that place requirements on a software product. The customer and users have requirements, which is what I would call "customer requirements". These are the characteristics of the system that the customer and the users deem necessary. However, requirements can also come from the business (the company producing the software), usually because of domain experience and insight into continuing to develop the product across customers. Requirements may also come from regulatory sources - governments, laws, industry standards.

The customer requirements may require grooming of some kind. Chances are, the customer won't hand requirements that are totally usable from a technical perspective. There may be inconsistencies, ambiguities, or incompleteness that needs to be resolved. However, even after grooming and buy-in, they are still customer requirements.

The engineering team takes requirements from these sources to develop the system (and subsystem / component) requirements that pertain to the particular product. These requirements are a refinement of the customer, business, and regulatory requirements. At the highest system level, they still need discussion and negotiation with the customer since business and regulatory requirements may conflict with customer requirements and these conflicts need to be resolved.

Functional requirements are simply a type of requirement. A requirement can typically be called a "functional requirement" or a "non-functional requirement". Non-functional requirements are also sometimes called "quality attributes". Any requirement (customer, business, or regulatory) could be functional or non-functional.

There are other things that may be included in requirements specifications. These are called design constraints - things that don't describe the functionality or characteristics of the software but impact your design. For example, if your customer only runs Windows environments, then the fact that your software is going to be deployed on Windows is a design constraint. Design constraints may also come from business or regulatory requirements, but usually customer or business requirements drive design constraints.

In your specific example, I would say that the user being able to enter data in a specific format is a user requirement. In order to maintain a product line or security needs, there may be business or regulatory requirements on data validation, data integrity, checksums, or hashing as well. Your system requirements would be enough information to someone to design and test a system. I'd call the use of Java and Oracle DB design constraints.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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