Cerificering
IIBA biedt
certificeringmogelijkheden voor business analisten en requirements engineers.
Men kan twee soorten examen afleggen:
1. CBAP – Certified Business Analysis Professional. Om dit
examen te kunnen doen moet men al voldoende jaren ervaring als business analist
hebben. Vervolgens moet men ook een moeilijke examen, gebaseerd op BABOK
(Business Analysis Body of Knowledge), afleggen.
2. CCBA - Certification of Competency in Business Analysis. Dit certificaat is
bedoeld als een certificataat voor professionals die nog niet aan een hoge eisen
van CBAP kunnen voldoen, maar wel de erkenning van hun kennis en kunde willen
krijgen.
In my experience use cases are very powerful tools - their purpose is show the view from a *user's point of view*. The presented example is already very technical, and specifies a lot of details.
May I offer alternatives to the example in the article?A) A few brief classic requirements (for business) & a diagram (BPMN or UML activity diagram) (for the engineers)B) A use case with a lot less details (maybe 4-8 steps) & user interface design & a list of business rules (describing the essence of the details)C) No use case. One single sentence describing the goal & rationale ("As a user I want to have a recovery method when I forget the password because ....") & brief description of the important parts, business rules (no flow details!) & user interface design
May I offer other improvements to the "classic" use case in the example?- Instead of a summary, formulate it as a goal (remove redundancy)- Adding how frequently this is done ("Frequency: seldom, max. once per month ... once every few years")- Keep the main flow under 10 points- Remove pre-conditions and post-conditions. Keep it simple.- Integrate the alternative flows into the main flow (if possible, leave away details)
User stories and backlog items don’t give the designers a context to work from
don’t give the project team any sense of “completeness
don’t provide a good-enough mechanism for looking ahead at the difficulty of upcoming work
Staring at the set of extension conditions in a use case lets the analysts suss out which ones will be easy and which will be difficult, and to stage their research accordingly
Here 5 reasons why I still write use cases
The list of goal names provides executives with the shortest summary of what the system will contribute to the business and the users
The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do.
The extension conditions of each use case provide the requirements analysts a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget
The use case extension scenario fragments provide answers to the many detailed, often tricky business questions
The full use case set shows that the investigators have throught through every user’s needs, every goal they have with respect to the system, and every business variant involved
how much should be written up front to get the project estimate into a safe place
several sticky parts for people using use cases
iteration/sprint lengths are so short that it is not practical to implement an entire use case in just one of them.
Writing good use cases (or any other requirements) requires thinking, communicating, and thinking again. It is much easier just to write user-story tags on index cards and let the project blow up later
We have adopted many of the concepts of Agile development—such as daily build and test, build the smallest piece of functionality that delivers value, etc.—but have retained our up-front work. It’s worked extremely well
Requirements Definition and Management for DummiesSmart businesses know that high-quality requirements are the cornerstone of any successful software development project. This fun and friendly ebook is an introduction to the role that is central to requirements: the Business Analyst. It explains why the role is so critical and how Business Analysts are transforming software projects.
Through the new practice guide and PMI-PBA certification, PMI will drive an awareness of the role globally that IIBA® has simply not had the resources to do
To obtain a PMI-PBA, first you complete an application that verifies you meet the following requirements:
Minimum of 3 years (4,500 hours) of business analysis experience within the past 8 consecutive years if you have a bachelor’s degree. (Or 5 years/7500 hours of experience if you do not.) (For comparison, the CBAP® requires 7,500 hours of experience and the CCBA® 3,750.)
2,000 hours working on project teams within the past eight consecutive years.
35 business analysis education (contact hours).
to support the ability for systems to change, we should be able to safely make big changes (supported by automated scenarios), as well as the small ones (supported by automated object specifications).
business goal, one or more actors, one or more impacts and one or more ways to support or prevent these impacts
You always start with the business goal; it is your map’s root node. You then grow the map out from the goal by first identifying all the actors (e.g. the customer or the team) that could help or prevent the project from achieving the goal. Each actor could have multiple ways to help or hinder achieving the goal, we call these impacts.
The last layer of an impact map defines what the project or delivery team can do in order to support or prevent particular impacts from happening, and this is the layer where your software options come into play.
In BDD we use Cynefin to identify which features require the most attention
Value and complexity analysis
reuse
outsource
Cynefin to make strategic planning decisions based on value/complexity analysis
Planning in examples
Usage-centered design
Ubiquitous language
eliminate the cost of translation
borrowed from DDD (Domain Driven Design)
'Given, describes the initial context for the example'When' describes the action that the actor in the system or stakeholder performs'Then' describes the expected outcome of that action
Introducing the three amigos
no single person has the full answer to the problem
For most enterprises moving to Agile, this is a new and critical role, typically translating into a full-time job, requiring one PO to support each Agile team (or, at most, two teams).
This role has significant relationships and responsibilities outside the local team, including working with Product Management, Customers, Business Owners, and other stakeholders
Without the right number of people in the right roles, bottlenecks will severely limit velocity.