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

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