Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Structuring and Organizing Requirements Specification
Previous Previous
 
Next Next
New Post 7/22/2013 10:19 AM
Unresolved
User is offline JBIT83
4 posts
No Ranking


Structuring and Organizing Requirements Specification 

 What are some good ways I can structure and organize the functional and non-functional requirements within my requirements document?  For example under the business process they support, classify them into major functions and then list the use cases underneath within the function followed by the requirement statements? 

Looking for some best practices here.


John B.
 
New Post 7/24/2013 10:04 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Structuring and Organizing Requirements Specification 

To systematically structure the processes/functions of a complex  manual and/or automated business system there is only one way:  Data Flow Diagrams for higher levels of abstraction and a sequence oriented technique for the more concrete.  Once you have your overall picture properly sturctured, you can do your stand alone use cases (but these really are not necessary).

With the above overall architecture, you have a vehicle to pigeon-hole your non-functionals into.

 

 

 
New Post 7/30/2013 7:57 AM
User is offline Sandy
74 posts
8th Level Poster




Re: Structuring and Organizing Requirements Specification 

Hi John,

From a documentation perspective, I would suggest an organization that is logical to the document's primary audience. If the document is meant to be reviewed (in part or in whole) by your business stakeholders, then grouping of related functions in some logical flow often works well. Note that this does not always correspond exactly to a business process flow, since it's not unusual for some functions to be shared across processes. And it may make more sense for business stakeholders to review related functions together even if they do not fall within the same process flow. For example, if you have a function to 'add new customer', business may find it easier to review and understand requirements if other functions related to customer information are grouped together.

Diagrams are always a great aid to supplement your requirements documentation. Diagrams such as use case models orfunctional hierarchies help business teams see each function within the broader context. You could incorporate these types of diagrams within your document to set the context for different sections of the document.

You will probably find many different perspectives regarding non-functional requirements. In my experience, these do not fit well into a use-case type organization, since by definition they are attributes of the system as a whole, rather than any specific function within it. So my suggestion would be to document these separately, or put them in their own section. If some function have specific non-functional requirements (e.g. a certain function has a specific requirement for performance or availability), these can certainly be incorporated into the respective use cases as well.

Sandy

 
New Post 8/21/2013 6:49 AM
User is offline y.meerbergen
3 posts
No Ranking


Re: Structuring and Organizing Requirements Specification 

 Hi Sandy,

thanks a lot for this very clear explanation.

I just want to add that, to be able to reuse the same requirement as needed, I use a Wiki. That way, for solution - functional requirements, I can have the comments from all the users/reviewers to which they apply, as they come into their flow as needed. 

For solution - non-functional, they should indeed be classified apart, except in the case you highlight.

Have a nice day.

Yannic

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Structuring and Organizing Requirements Specification

Community Blog - Latest Posts

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC