Requirement Engineering with vRA

One does not simply, bring software developing processes to an infrastructure focused territory

In this post I’ve tried to jot down one possible way with a highlevel view to have the activities between new ideas and delivery of new features sorted and organized in a requirement process, priorizied in a release management and developed in sprint cycles.

As well I’ve added the integration of Confluence and Jira system (mostly used for this job) but for sure this works with other systems als well.

Highlevel process landscape

Requirement Engineering, Release Management with vRA

This diagram was made with and can be downloaded here:

Roles & tasks with RACI model

In this table the RACI model should give a brief overview which role is in charge working on the particular task, who should be consulted and who is accountable.

TaskProduct OwnerArchitectRelease ManagementRequirement EngineeringProcess OwnerDevelopment
Adding and planning new Features and User Stories to Shortlist determined and refined based on business requirements.RARIC
Refinement of the requirements / user stories.IIRAR
Priorisation based on Product- and Release-RoadmapCCRAI
Tracking dependencies on incoming requirementsRRRA
Documentation of requirement (incl. system analysis, requirement and system design) in collaboration of all stakeholdersCRA
Regulary planning of product increment in a 1-2 day workshop.RACR
Post PI planning tasks like documentation and estimation of development stories.IRA
Sprint planningCRA
Integration & QA / testingAR
Verification and approval of new devoloped and integrated feature.IIRAC
Realasing new features, information of stakeholders and staging of environments.IRA
Table: RACI model for summarized tasks in process
  • R: Resposible – Person working on activity
  • A: Accountable – Person with decision authority
  • C: Consult – Key dstakeholder who should be included in decision or work activity
  • I: Inform – Needs to know of decision or action

Requirement documentation (example)

This section provides a structure to organize the use case documentation, more or less this sequence could be used to work on the documentation. It starts with a section “user story” and “system analysis” and is fairly simple. A user story shouldn’t be too technical and even understandable by the end user. The system analysis handles the discovery and questions like: “what’s required by simple steps in this story?”, “where to get the information from?”, “which systems are involved?”
Requirements, it’s barren or bald, yes. But this part is somehow the law and ruels for any involved. There could be 100 diagrams describing a procedure. To have this procedure documented without diagrams you would need 100 x 1000 words, right? Yes, but at the end there are still different interpretations resulting from it… That’s why bald and dry sentences including words like “must” and “must not” are required. At a verification phase these requirements are used to determine if what was required had been implemented.
In the section system design, dependencies between actions and involved systems are a key part and discussions in “grooming session” between requirement engineering, architect, process owner and engineers of involved systems.

User story

A short story in a user perspective. Whats the users background, what, why and where he expect to request. Do not be concrete about where an activity happens. Just keeping all systems, for instance vRA, Ansible and so on, in one box like “automation system”.

(if needed) some interview questions followed:

  • What’s the user expected output?
  • What’s the users background (Business Unit, etc.)
  • Are there followed up task? Like additional configuration usually happens 2-3 weeks laster…
  • How’s the user accessing this resource?
  • Is there an approval line required?

As a application manager I’m able to request a windows server update bundle for my managed windows server. If provided services provided with this servers are not working afterwards, decided by the application manager, a restore would be possible and asked by the automation system.

System Analysis


This sections holds a list of preconditions based on the user story. This differs from assumptions as this preconditions are clear and based on them the use case is designed.

NumberTitlepre Condition
precon-001managed machinethe managed machine needs to be managed by vRA
precon-002vSphere VMthe aimed machine by the user is hosted in a managed vSphere Cluster
Table: Assumptions


Not simple ignore spots that can not be clearified or would take to much time for a clearification, thus write it down to have the facts clear to understand a decision in this documenation in a later state.

NumberTitleAssumptionaddressed to
asp-001Decision of Windows UpdatesApplication owner is able to determine if provied list of windows updates will harm to application or not.Architect / PO
asp-002further troubleshootingAfter problem report, if any restore proceder triggered by the automation system, no further action is triggerd by the automation system. This process is done manually.Process Owner
Table: Assumptions


This section should list all known data which flows in and out during this process / use case. Some data will be missing in this list but will be concrete in a later phase of requirement.

As well, this sections shows the data from a user perspective, not every bit needs to be listed here.

Which data flows into and which data will be served as output?
Which data is used for specific sub-task, where to get this data from?

NumberNameDatatypeDescriptionProvided by
inp-002searice healthbooleandescfunction: getServiceState
inp-003AppOkbooleandescUser Interaction (1)
inp-004AppOkbooleandescUser Interaction (2)
inp-005IssueResolvedbooleandescUser Interaction (3)
Table: Input
NumberNameDatatypeDescriptionProvided to
out-001installed UpdatesString / eMailList of installed windows updatesRequestor / User
Table: Ouput

Involved Systems

This section provides just a list as a outcome of discussion to help starting with a UML or a activity diagram. Something like:

  • Scripting Host » PSS initate Windows Updates
  • vRA » handels request
  • Monitoring » holds the services state before and after
  • vCenter » snapshot & restore

UML & Activity Diagram

Dependencies to other Use Cases and modules

NumberDependend UseCase Nr+TitleTasks that dependsrequired output/task
depUc-001UC-055 – Snapshot Handlingcreate snapshot, delete snapshot, restore snapshot
depUc-002UC-061 – service stateExamine machine / service monitoring stateboolean
Table: Dependencies to other proceses & use cases


Best organized in a table like in the followed table.

NumberRequirement TitleRequirementCriteriaSystem
req-001FormThe vRA catalog item provides a form which will ask the user all nessecary but few as possible and will not allow to request a invalid combination of input data.must havevRA
req-002Form ValidationThe user is not allowed to request an update cycle for machines their service is downgraded in the monitoring system.must havevRA Form
req-003FormAll windows updates of WSUS (Windows Update Serivces) provided will be shown to the user in request formmust havevRA From
req-004ChangeA standard change will be issues in prior to any action on the system.must havevRA
Table: Requirements

System Design

Process Swimlane Diagramm – UseCase: Windows Update Cycle

Jira structure

Example of a Jira structure

Epic – UseCase

State Cycle: Open – UserStory- System Analysis – Requirements – System Design – DocApproval – Development – Verification – Closed

Reporter: Requirement Engineering
Assignee: Scrum Master / Requirement Engineering

Descripton: User Story + Link to Documentation

Story – Development Story

State Cycle: Open – InProgress – Closed – Reopen – Closed – Done

Reporter: Development
Assignee: Development