Users often want to see all the ways a system can be used. This is, of course, the purpose of a use case model.
One subtlety is that a use case does not show you what you are doing, but what you could do. A scenario, of course, will show you what you are doing, including a link to the user interface if you like. It’s the difference between a class and instance.
Well formed use cases often contain a structure like:
The Actor can choose to update any of the following:
Item 1
Item 2
Item 3
Etc.
The use case does not tell you what is actually being done or the values entered. But a scenario would: “The Actor enters “123” for Item 1 and “June 10, 2009” in Item 3.
It is the combination of use cases and scenarios that assure the customer you understand all the ways a system can be used. There are a number of tools in the marketplace that support this approach to documenting functional requirements.
Sunday, June 21, 2009
Friday, July 06, 2007
REPRESENTING IIBA'S BODY OF KNOWLEDGE IN AN OPEN SOURCE, STANDARDS-BASED PROCESS FRAMEWORK
(EXAMPLE at Processential.org)
You can represent the business analysis responsibilities described in IIBA’s BA-BOK in a process framework. Using a model derived from the Object Management Group (OMG) industry standard Software Process Engineering Meta-model (SPEM), it is possible to show business analysis activities within the context of software development and management processes. One approach is to use tooling and content from the Eclipse Process Framework (EPF), an open source project within the Eclipse Foundation. This allows configuration of your process by selecting relevant material, and publishing it as a Web site. The result is a process that integrates business analysis activities with those of the rest of the organization.
Technorati tags: EPF, SPEM, OMG, IIBATuesday, May 01, 2007
A GLOBAL SURVEY OF AGILE PROJECT MANAGEMENT TOOLING
Among the findings:
* Agile adoption still appears to be in an early adopters phase according to Geoffrey Moore’s definition in “Crossing the Chasm”;
* Scrum is the most prevalent process in use to-day, but is often integrated with other agile practices and methods ;
* Larger companies only have a fraction of their development organization staff following agile processes and smaller ones are only just over half-penetrated;
* Organizations use a range of tools to manage their agile process, even if they have purchased a dedicated agile project management tool ;
* Agile project management tools have overtaken manual approaches across all companies ;
* Smaller companies are just as likely (if not more so) to use agile project management tooling than large companies; though some of their reasons differ.
Among the findings:
* Agile adoption still appears to be in an early adopters phase according to Geoffrey Moore’s definition in “Crossing the Chasm”;
* Scrum is the most prevalent process in use to-day, but is often integrated with other agile practices and methods ;
* Larger companies only have a fraction of their development organization staff following agile processes and smaller ones are only just over half-penetrated;
* Organizations use a range of tools to manage their agile process, even if they have purchased a dedicated agile project management tool ;
* Agile project management tools have overtaken manual approaches across all companies ;
* Smaller companies are just as likely (if not more so) to use agile project management tooling than large companies; though some of their reasons differ.
|
Technorati Tags: Agile, SCRUM
Wednesday, April 25, 2007
Atern, the new agile framework from DSDM Consortium, was launched this week.
Atern is founded on expertise gained by practitioners in a wide variety of public and private sector projects during the last decade. It is a robust, but agile, project delivery framework which can be used on IT projects, business change programmes and in all industrial sectors to achieve on-time and in-budget delivery.
Latest information on Atern can now be accessed at www.dsdm.org. It is free to view and use for end-users.
Technorati Tags: Agile, Atern, DSDM, process framework, process
Atern is founded on expertise gained by practitioners in a wide variety of public and private sector projects during the last decade. It is a robust, but agile, project delivery framework which can be used on IT projects, business change programmes and in all industrial sectors to achieve on-time and in-budget delivery.
Latest information on Atern can now be accessed at www.dsdm.org. It is free to view and use for end-users.
Technorati Tags: Agile, Atern, DSDM, process framework, process
Tuesday, April 03, 2007
A Quick Example for Agile Wording
Too many words wear one down quickly and discourage reading. The left column is the original OpenUP content. The right column is the revision after the first iteration. Applying the word 'iteration' to content is quite intentional. Quality agile content requires early and constant revision. Mere copy-editing at the end is inadequate.
One can argue that meaning has been lost. If so, let's have another iteration on this content!
(example from OpenUP:Guideline: Use-Case Model)
Technorati Tags: EPF, OpenUP, Agile,
process
Wednesday, March 28, 2007
Agile Language for an Agile Process
What exactly do we mean by agile language?
Agile software development assumes minimal process definition. We are all overloaded with information. Developers would like to invest the minimum amount of time necessary to grasp a new concept or to look up information.
Using a tool like EPF is a good way to capture process. The real goal is to produce language that communicates ideas as efficiently as possible. Language itself is important and there is no substitute for good writing.
Since the final product is words, and perhaps pictures, iterative development is appropriate. Concise and efficient communication requires several re-writes. This is quite different than editing or a final copy edit. Quality must be built in. Consult any good technical writing guide and apply it to each and every version of content you create. Look for the most direct means of expression. Avoid unnecessary qualification. Do not create content, just for the sake of populating the process elements of your model.
The result can be an agile development process that developers will read.
Technorati Tags: Agile,, EPF,, OpenUP,, Process
What exactly do we mean by agile language?
Agile software development assumes minimal process definition. We are all overloaded with information. Developers would like to invest the minimum amount of time necessary to grasp a new concept or to look up information.
Using a tool like EPF is a good way to capture process. The real goal is to produce language that communicates ideas as efficiently as possible. Language itself is important and there is no substitute for good writing.
Since the final product is words, and perhaps pictures, iterative development is appropriate. Concise and efficient communication requires several re-writes. This is quite different than editing or a final copy edit. Quality must be built in. Consult any good technical writing guide and apply it to each and every version of content you create. Look for the most direct means of expression. Avoid unnecessary qualification. Do not create content, just for the sake of populating the process elements of your model.
The result can be an agile development process that developers will read.
Technorati Tags: Agile,, EPF,, OpenUP,, Process
Wednesday, March 07, 2007
Getting a handle on the IIBA's BABOK
The BABoK is a large document representing the experience of the many talented business analysts who volunteer their time to document their knowledge. Yet it is not the kind of document one would pick up to understand how to apply BA knowledge to a particular project. That may not, or course, be the purpose of the document. It's really meant more to further effort toward standardization of BA as a profession.
Nonetheless, it's fair to ask how to apply the material or how it can be made actionable. The IIBA could apply a basic BA technique to make the material approachable for the average practitioner. Specifically, applying a process model to BA activities can be useful.
A basic modeling technique would be to start with the actors and associated processes. This usually leads to role clarification. If we look at the BABOK, we see one role: Business Analyst.
I suggest that the BABOK material could be organized using more role granularity. While the range of BA activities may be broad, it is clear that the processes with which a BA becomes involved require more specific role descriptions. Looking to some existing process frameworks can provide guidance. RUP, for example, defines many different roles, some of which overlap with those described in the body of knowledge.
As I have written elsewhere in this blog, SPEM is a good model for capturing method and process material. It facilitates clear thinking about the roles, activities and work products and how they relate to each other.
Once you have a clear organization of BA activities, advice and best practices, you have taken a crucial step toward the ability to put it into practice. Open source process authoring tools are available (e.g. EPF) that allow you to take BA best practices and generate a plan specific to your project.
Technorati Tags: EPF, SPEM, IIBA, BABOK
The BABoK is a large document representing the experience of the many talented business analysts who volunteer their time to document their knowledge. Yet it is not the kind of document one would pick up to understand how to apply BA knowledge to a particular project. That may not, or course, be the purpose of the document. It's really meant more to further effort toward standardization of BA as a profession.
Nonetheless, it's fair to ask how to apply the material or how it can be made actionable. The IIBA could apply a basic BA technique to make the material approachable for the average practitioner. Specifically, applying a process model to BA activities can be useful.
A basic modeling technique would be to start with the actors and associated processes. This usually leads to role clarification. If we look at the BABOK, we see one role: Business Analyst.
I suggest that the BABOK material could be organized using more role granularity. While the range of BA activities may be broad, it is clear that the processes with which a BA becomes involved require more specific role descriptions. Looking to some existing process frameworks can provide guidance. RUP, for example, defines many different roles, some of which overlap with those described in the body of knowledge.
As I have written elsewhere in this blog, SPEM is a good model for capturing method and process material. It facilitates clear thinking about the roles, activities and work products and how they relate to each other.
Once you have a clear organization of BA activities, advice and best practices, you have taken a crucial step toward the ability to put it into practice. Open source process authoring tools are available (e.g. EPF) that allow you to take BA best practices and generate a plan specific to your project.
Technorati Tags: EPF, SPEM, IIBA, BABOK
Subscribe to:
Posts (Atom)
