Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Service, System, Stakeholder, Software-Requirement
Previous Previous
 
Next Next
New Post 2/15/2013 3:56 AM
User is offline erikhultgren
2 posts
No Ranking


Service, System, Stakeholder, Software-Requirement 

Hi!

Im quite new to this requirement documentation thing and im sitting right now try to understand and work with all this. I found the new ISO/IEC/IEE 29148:2011 standard which gives me tree different templates. One is for Software, one for System and one for Stakeholders.

Im not that intrerested in Software, but let's say im looking in to system requirement. Many times these system are outsourced in some way, not only the development but also support and other stuff like hosting servers etc.

Im having a hard time to find how to structure a good template including all these service requirement. Are there like a standard that you should use Service requirement document when for example using SaaS, or is that just non-functional requirements within System requirement document?

Is it possible to merge the service requirement into the system requirement template or should you like have a special Service requirement document?

Really appricate all inputs on this topic!

 

 
New Post 2/15/2013 11:34 AM
User is offline Sandy
74 posts
8th Level Poster




Re: Service, System, Stakeholder, Software-Requirement 

At a very basic level, the primary purposes for documenting requirements are to communicate what is needed (whether buiness process, software functional & non-functional capabilities, or services); and to monitor and manage delivery on those requirements.

For business processes and software systems, there are generally quite a few steps in between the communication of the requirement and the ultimate delivery that need to be managed.  Requirements documentation templates and practices are built to support this end-to-end tracking.  For functional requirements, for example, you may start with a use case that gets translated into class diagrams, design specifications, test cases, etc.

Services tend to follow a bit different path, so my suggestion would be to focus on the life-cycle for your service requirements.  I would suggest looking at ITIL for service management rather than ISO if your focus is primarily on services (whether insourced or outsourced) :

http://www.fastitiltemplates.com/service-design/service-catalog.html

If you expect to end up producing some type of service level agreement from your service requirements, this will take you right down that path.  The link above has some good examples for building a service catalog, which can be a great way to document service requirements.

Sandra

 
New Post 2/21/2013 3:30 AM
User is offline erikhultgren
2 posts
No Ranking


Re: Service, System, Stakeholder, Software-Requirement 

Thx Sandra!

I have been working on with my requirement document! Thanks for your input!

The ITIL template will do fine for my service requirements!

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Service, System, Stakeholder, Software-Requirement

Community Blog - Latest Posts

Salesforce has established itself as one of the most reputable CRM platforms, providing important customer data to assist businesses in effectively managing their operations. Salesforce is the world's best CRM platform that helps businesses to keep up the data in an arranged or structured manner. Salesforce is the world's most popular...
There are big differences between data exploration versus data presentation. And you need to be aware of these differences as you're creating data stories and data presentations. Let’s start by defining our terms: Data exploration means the deep-dive analysis of data in search of new insights. Data presentation means...
Is Agile a reason to avoid documentation? I bet this question shows up again and again while working with product requirements. On one side, we have got long specifications, complicated diagrams, mystical technical design, too many prototypes and pretty obvious for engineers user guides (do we really need so much?). On the other side, can we actual...

 






 

Copyright 2006-2022 by Modern Analyst Media LLC