- Deep understanding of subject matter provided numerous advantages that improved overall efficiency and reduced costs for the organization or project. (a) Better inter-relationship because of similar mindsets and usage of the same jargon. (b) More concretely, I didn't have to elicit content from SMEs; I gathered them independently. That includes, for example, reading code or at a higher level, understanding system architecture whether designed or to be designed. This minimized distracting the SME from their normal work. (c) Even if they don’t mind, there is overhead. It costs essentially twice as much (that of the SME’s and my time). As equivalent to the SME, I was able minimize this. (d) As equivalent to SME but having external perspective, I was able pick up on details while not missing the forest over the trees. Thus my deliverables were easily adapted to a wide range of target audience: the public, business managers and technical users (other Developers for example).
- High level information from requirements gathering sessions was digested and converted into requirements. Requirements were not only elicited in the sense of paraphrasing those provided by the Domain SME but defined - that is, actively suggesting functional and non-functional requirements. Many supporting skills provided perspective in understanding causal factors and foresee conditions to ensure favorable outcome. For example, experience as Developer, Usability Professional and QA applied during business analysis aided in defining non-functional requirements of usability, reliability, performance, security, compatibility, maintainability and transferability. This was performed in collaboration with many stakeholders including Domain SMEs and Sponsors.
- When requirements needed to be translated into specifications (in, say, waterfall and iterative-incremental projects) or refined as user stories (agile), I was able to assess coding effort required. For example, what looked easy may be identified early as requiring effort not feasible in present form given budgetary or time constraints whereupon it was then reported to the Project Manager and Lead Developer. Or what was believed to be a “nice to have” may in fact require only a few extra lines of code and a server setting. Thus specifications, high level design or stories were tweaked in consultation with relevant stakeholders to best exploit capabilities of available technology of which I continually keep up to date. I collaborated with the Project Manager, System Architect and Developers to accomplish this.
- When creating test cases in the context of traceability (requirements tracking), business requirements were organized in order to make validation easy to perform on manageable pieces while ensuring test cases were accountable to all acceptance and evaluation criteria. In agile environments, stories were broken down into smaller ones, elaborated upon or recombined. In the waterfall model, each tier was phrased such that it became the criterion for next in the cascade. For example, any numbered requirement in the business requirements document (BRD) became, at a high level, the first paragraph verbatim in the corresponding software design specification (SDS). In turn, detailed sub-specifications were phrased such that they became the first sentence verbatim in the corresponding test script. The whole process required a clear picture of everything which my method of wording and numbering in the cascading taxonomy tree made all elements easy to track. That is but one example where my Quality Management Systems experience was applied while working with Developers and Testers.
- Where appropriate, SDS documents were authored using (since they are the target audience) developer-friendly jargons, techniques and tools such as UML, data models, data and process flow. Same held true of scenarios and use cases, functional and non-functional requirements, business rules, gap analysis, root cause analysis and other techniques of business systems analysis for their target audience. This did not necessarily require collaboration with other stakeholders (who really should not be distracted from their primary activities beyond minimal necessary) but employed a technical background that allowed one to independently produce useful, high quality artifacts of analysis, such as documentation and presentations, for consumption by other stakeholders.
- In summary, each of these examples demonstrates a recurring pattern of clarified, enriched, novel and useful content forming a coherent whole - what a highly capable technical communicator and analyst should do - from the perspective I bring as a result possessing strong, diverse supporting technical skills. My roles can be summarized visually in context according to the International Institute of Business Analysis (IIBA) and self-assessement of proficiencies each on a scale out of 3 (you can see where they cluster):