Skip to main content

Home/ BARE+IA Requirements Engineering Information&Business Analysis/ Group items tagged Business

Rss Feed Group items tagged

Peter Van der Straaten

BDD,Cucumber,Gherkin,User Stories,use cases,TDD - IT Jobs Watch Search - 0 views

  • TDD34-8£60,000-6,064 (6.48%)1,470
  • BDD109-29£60,000+3.44%2,823 (3.02%)607
  • User Experience43+8£55,000-5,279 (5.65%)1,045
  • ...9 more annotations...
  • User Stories1730£55,000-1,814 (1.94%)335
  • DescriptionRank6 Months to27 May 2021RankYoY ChangeMedian SalaryMedian SalaryYoY ChangeHistoricalPermanentJob AdsLiveJobs
  • Cucumber279-20£60,000+14.28%1,051 (1.12%)143
  • User Acceptance Testing284-56£47,500-5.00%1,039 (1.11%)193
  • Business Cases311-71£56,878-5.20%932 (1.00%)210
  • Use Case3170£63,500+10.43%917 (0.98%)206
  • User Experience Designer443-30£52,500-4.54%581 (0.62%)101
  • Gherkin598-4£52,500-331 (0.35%)45
  • Epic User Stories616+64£57,542-7.93%304 (0.33%)50
Peter Van der Straaten

IIBA Certificering - 0 views

  • 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.
Peter Van der Straaten

Use Cases for Business Analysts - The New School - 0 views

  • 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)
Peter Van der Straaten

BABOK Agile Extension | IIBA - 0 views

  • The Agile Extension to the BABOK® Guide
  • The importance of business analysis practices
  • How business analysis is performed in agile lifecycles
  • ...4 more annotations...
  • Key principles
  • How agile practices modify business analysis tasks, and existing techniques
  • collaborative effort between the Agile Alliance and IIBA
  • submit that feedback before January 31, 2012
  •  
    BABOK, CBAP, CCBA & Certification from International Institute of Business Analysis
Peter Van der Straaten

Alistair.Cockburn.us | Why I still use use cases - 1 views

  • XP pretty much banned use cases, replacing them with the similar sounding “user stories”
  • Scrum did similar, using the “product backlog” instead of user stories
  • Yet as I go around projects, I keep running across organizations suffering from three particular, real, painful, and expensive problems
  • ...15 more annotations...
  • 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
Peter Van der Straaten

eBook: Requirements Definition and Management for Dummies - Blueprint Software Systems - 0 views

  • 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.
    • Peter Van der Straaten
       
      Content quite superficial; It's somewhat usefull for RE, RM and BA newbies. Mostly advertises the blueprint tool
  •  
    VALT TEGEN: Relatief oppervlakkig, en meer een vehikel om eigen tool aan de man te brengen.
Peter Van der Straaten

The PMI-PBA vs. IIBA CBAP or CCBA - 0 views

  • 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).
Peter Van der Straaten

InfoQ: IIBA announce Agile Extension to the Business Analysis Body of Knowledge - 1 views

  • IIBA(tm)) announced the release of a draft of the Introduction for the Agile Extension to the Business Analysis Body of Knowledge (BABOK
  • many business analysts are struggling to understand how the role changes in Agile projects
  • "weak" or "sham" Agile implementations in organisations where "doing Agile" is not accompanied by any real cultural or governance change
  • ...2 more annotations...
  • public draft of the introduction to the extension.  This is available from the IIBA website 
  • Simultaneously Chris Matts and others formed the Agile BA Requirements Yahoo group
  •  
    Also other remarks on Agile and BA
Peter Van der Straaten

Cawemo | Welcome - 0 views

Peter Van der Straaten

Use cases or business process maps, what technique to use? - 0 views

  • shed some light on the difference between process maps and use cases.
  • different techniques and basically the result is the same
  • if you’re more comfortable with use cases then stick to them or if you’re more familiar with process maps then draw a map
Peter Van der Straaten

The beginner's guide to BDD (behaviour-driven development) - 0 views

  • 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).
  • Impact mapping
  • mind mapping
  • ...19 more annotations...
  • 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
  • business person, a developer and a tester.
  • Development through examples
  • The BDD loops
  • How we use it
Peter Van der Straaten

Product Owner - Scaled Agile Framework - 0 views

  • 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.
1 - 20 of 56 Next › Last »
Showing 20 items per page