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

This diagram was made with draw.io 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.
Task | Product Owner | Architect | Release Management | Requirement Engineering | Process Owner | Development |
---|---|---|---|---|---|---|
Adding and planning new Features and User Stories to Shortlist determined and refined based on business requirements. | RA | R | I | C | ||
Refinement of the requirements / user stories. | I | I | RA | R | ||
Priorisation based on Product- and Release-Roadmap | C | C | RA | I | ||
Tracking dependencies on incoming requirements | R | R | RA | |||
Documentation of requirement (incl. system analysis, requirement and system design) in collaboration of all stakeholders | C | R | A | |||
Regulary planning of product increment in a 1-2 day workshop. | RA | C | R | |||
Post PI planning tasks like documentation and estimation of development stories. | I | RA | ||||
Sprint planning | C | RA | ||||
Development | RA | |||||
Integration & QA / testing | A | R | ||||
Verification and approval of new devoloped and integrated feature. | I | I | RA | C | ||
Realasing new features, information of stakeholders and staging of environments. | I | RA |
- 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?
Sample:
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
Preconditions
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.
Number | Title | pre Condition |
---|---|---|
precon-001 | managed machine | the managed machine needs to be managed by vRA |
precon-002 | vSphere VM | the aimed machine by the user is hosted in a managed vSphere Cluster |
precon-003 | … | … |
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.
Number | Title | Assumption | addressed to |
---|---|---|---|
asp-001 | Decision of Windows Updates | Application owner is able to determine if provied list of windows updates will harm to application or not. | Architect / PO |
asp-002 | further troubleshooting | After 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 |
asp-003 | … | … | … |
I/O
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?
Input
Number | Name | Datatype | Description | Provided by |
---|---|---|---|---|
inp-001 | vm | ManagedMachine | desc | User |
inp-002 | searice health | boolean | desc | function: getServiceState |
inp-003 | AppOk | boolean | desc | User Interaction (1) |
inp-004 | AppOk | boolean | desc | User Interaction (2) |
inp-005 | IssueResolved | boolean | desc | User Interaction (3) |
Output
Number | Name | Datatype | Description | Provided to |
---|---|---|---|---|
out-001 | installed Updates | String / eMail | List of installed windows updates | Requestor / User |
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
Number | Dependend UseCase Nr+Title | Tasks that depends | required output/task |
---|---|---|---|
depUc-001 | UC-055 – Snapshot Handling | create snapshot, delete snapshot, restore snapshot | – |
depUc-002 | UC-061 – service state | Examine machine / service monitoring state | boolean |
Requirements
Best organized in a table like in the followed table.
Number | Requirement Title | Requirement | Criteria | System |
---|---|---|---|---|
req-001 | Form | The 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 have | vRA |
req-002 | Form Validation | The user is not allowed to request an update cycle for machines their service is downgraded in the monitoring system. | must have | vRA Form |
req-003 | Form | All windows updates of WSUS (Windows Update Serivces) provided will be shown to the user in request form | must have | vRA From |
req-004 | Change | A standard change will be issues in prior to any action on the system. | must have | vRA |
req-005 | … | … | … | … |
System Design

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