IT Solutions Architects and Cyber Security Engineering
Michael W. Meissner is a Enterprise Architect with Ethernautics, Inc. and leads Ethernautics Information Technology Enterprise Architectures Practice. Mr. Meissner has over thirty years of experience conducting and managing Requirements Engineering; Requirements and Systems Analysis and Knowledge Engineering efforts. Meissner has in depth experience across the project life cycle and continues to work with clients collecting requirement and successfully executing solutions delivery. Expertise in multiple SDLC concepts and the inter-dependencies of documentation
Requirements analysis is an instrumental part of the traditional SDLC. The SDLC in the parlance of the times refers to the Systems Development Life Cycle or the Software Development Life Cycle. The SDLC can also refer to Solutions Development Life Cycle. That reference as an acronym is an under-characterized as such the Development Life Cycle is relevant to construction of almost any “Development” Project, be it software, system, Set Top Box (STB), even a Wireless Infrastructure, Shopping Mall, Nuclear Power Plant or Water Distribution System.
In theory, at the inception of any idea for any product plans are made, requirements are gathered from those plans, transposed to design speak, designs are implemented (delivered, built, constructed), and the resultant product is turned over for maintenance (production, operations, occupancy, etc.)
Requirements Engineering: Requirements Analysis, Systems Analysis or Knowledge Engineering as a process of determining user expectations/market need for a new or “smarter” modified product. Project requirements analysis produces traceable and reference-able documentation for design, test, deployment and maintenance of for a variety of “products”; Software, Hardware, Infrastructure, Material, Process or any combination thereof. That product may also be more physical in nature, such as a Building Structure or Plant. The features of the end state product are referred to as requirements, must be quantifiable, attainable, relevant and detailed. Overall the product must be “constructable” within constraints; Budget, Schedule, Resource, and Technical Acumen must be achievable or the requirement is deemed out of scope. In software engineering, such requirements are called functional specification.
A Requirements Analyst, is a professional who documents requirements, defines scope and objectives, and formulates systems to parallel overall business strategies.
Ultimately requirements analysis should also be able to provide a baseline for measures of performance, risk analysis and mitigation, and compliance.
Systems analysis differs from requirements analysis referring more: to the technique of “reverse engineering” or destructing the “in situ” systems or software, resolving it into components in order determine how it works or performs its expectations.
Business requirements analysis captures the business process, what the process is and how the process is executed. Transforming the business needs; “Engineering”, and transforming that requirement into a design that is constructable and is delivered into a working product.
The successful facilitation and collection of a complete set of requirements of any given SDLC project requires analysis interaction with the other phases of the SDLC during all phases of the SDLC.
The design process involves the following:
Note the inclusion of Bidding Documents and Construction Administration Steps. Atypical in most Systems Design discussions but found extensively in the realm of Architecture and Construction particular that are applicable in IT Infrastructure requirements and design.
The design steps can be more concisely presented as follows.
Industry practice and contracts often will call for 30-60-90% reviews of design from concept through the issuance of design documents that are ready for “construction”. Typically, there is a final Owner Acceptance Review (OAR) at 100%. The design in fact may NOT be complete at that point. But the owner excepts it as 100%. Future changes are made through Design Change Request (DCR), Engineering Change Request (ECR), or sometimes just Change Request (CR).
This approach being more traditional with modern methodologies (i.e. Rapid, Agile), Shorten the design cycles and opt for a higher number of iterative design build release evolutions. Which works nicely for software and software intensive systems but not so well for traditional design build projects. The 30th floor Data Center design and build cannot complete until the supporting infrastructure of walls and floors are complete.
Interaction with other Phases and Functions is the primary to the success of successful gathering, documenting and implementing requirements.
Interaction is meant as exactly that, requirements analysis is a skill of communications. Requirements are a two way or multiple input interaction. For example, requirements are taken as an inception idea interaction from Planning (R&D, Marketing, etc.). That business requirement is transposed to a set of requirement that is understood by both design engineers and management.
Early, close and frequent collaboration with engineering groups (i.e. systems engineering, software engineering, database engineering, architectural, electrical, test) have proven produce superior quality artifacts as requirements developed from interaction with planning and Subject Matter Experts (SME) are vetted against and transformed into technical requirements. Requirements analysis are those tasks that go into effectively formulating the needs or specifications to meet for a new or improved product, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.
The SDLC represents a life cycle, it is common for the referenced phases of the life cycle to be representing in practice by different organizational functions.
Requirements Engineering is required across the SDLC, as such interactions with both business and technical subject matter experts (SME) during the engagement of the process. Regardless of the development methodology (Waterfall vs. Agile) requirements engineering is involved from inception thru design, deployment and operations.
Requirements Engineering collaborates with what is referred to in the SDLC as Planning, which represents the business facing efforts involved. Requirements Engineering interfaces with, collects and reflects requirements with functional areas and their personnel that represent more of the business aspects of a Life Cycle. The represent functions within ‘planning”: Governance, Program and Project Management, Finance, Legal and Compliance, etc.
Requirements Engineering important and close collaborating with those from Technical functional areas. Those functional areas could include disciplines from IT Engineering, Design Engineering and others depending upon the project.
Requirements must be understood and communicated between the business functions, technical functions and the operation functions of the organization.
If the SDLC is taken as a linear process as in traditional Waterfall Method. Requirement are gathered in entirety before the design and implementation begin. As can be seen the skills needing to be involved to bring a product from inception through production gets more involved as the SDLC progresses and the need to gather requirements from downstream groups (Operations, Training, Facilities). It is common for Requirements Engineering to be involve over the entire Life Cycle of the project.
Requirements are typically gathered at the front end of projects as many of the requirements have their provenance in the planning stages. Ensuring success relies upon Requirements Analysis interfaces and involvement from Project Planning thru design and implementation/deployment and ultimately into operations and maintenance.
Due the interactive cross-multi-functional nature of Requirements Engineering diplomacy skills and the ability to collaborate are tantamount to success
Requirement Analysis for design projects, be they physical construction, software development or systems development efforts, are typically gathered at the front end of projects as many of the requirements have their provenance in the planning stages. Ensuring success relies upon Requirements Analysis interfaces and involvement from Project Planning thru design and implementation/deployment and ultimately into operations and maintenance.
Like many other factors the architecture of the product highly influences the requirements methods employed and the nature of the requirements to be gathered and documented.
Depending upon design methodologies chosen by the organization. Requirement Analysis can be iterative and short in duration or a long and thorough process. Requirements analysis interfaces with planning, project management and SME from the Operational organization and design engineering in order to articulate planning requirements and capture the business and technical requirements of the design.
Requirements Analysis requires an understanding of the development methodologies that are employed by the organization. Most methodologies are found to be based on the SDLC. The SDLC has evolved over time and many organizations choose to deploy hybrid methods that shorten the requirements-development-test-deployment cycle into smaller iterative coding functions. The following is a non-inclusive list of development methodologies.
Details of the methodologies are available throughout a plethora of resources and are only covered in light detail in this document.
Adherence to Best Practices, Standards and Local Codes leads to a higher quality product that is maintainable, extensible, and leverages organizational investment in capital assets.
Organizations SHOULD adhere to the following standards when writing specifications and policy for asset management, system management and security. Strict adherence to best practices leads to higher availability, extensibility and maintenance.
And as an integral part of configuration management it is also relevant for Cyber Security best practice.
Writing skills are paramount importance to successful requirements analysis. Proficiency with use of general office applications tools (i.e. Microsoft Office Suite: Word, Excel, PowerPoint, Visio, Project, SharePoint or equivalent) are minimum requirements.
Documentation methods for requirements vary by organizations as requirements documentation can be highly sensitive corporate intellectual property.
Documents requirements, defines scope and objectives, and formulates systems to parallel overall business strategies.
Some Techniques utilized today are use case and Unified Markup Language (UML).
Requirements gathering during the analysis process must be traceable. Many attributes and important KPI’s (i.e. Performance, Quality) are captured by meticulous requirements traceability. It is essential for Testing the completeness of code and quality of results.
Many tools are available on the market for tracking requirements. Many organizations’ simply track requirements via spreadsheets or ticketing systems.
Quality Assurance Requirements also vary by organization as some organizations are more sensitive to quality than others. This can be due to regulatory requirements or a matter of pride in workmanship or sensitivity to market timing.
It is advisable that a minimum set of Quality Standards particularly for software and material be established by the organization.
Requirements analysis often interfaces to Project Management and Program Management Office for many planning requirements (i.e. Budget, Schedule, Resource requirements). Often the task of tracking project performance falls to the requirements analysis function as many performance KPI’s I tied to the completion and documentation of a requirement.
Often a professional Certified Project Manager is deployed on larger project to administer project management task, resources, schedules, financial performance, etc.
Requirements Analysis is phase that requires a functional skill largely in human interaction and communications, verbal, written, and those elusive nonverbal, read-between-the-lines, professional tact. Thus it cannot be more strenuously emphasized the most important skill required in the requirements analysis phase is diplomacy.
Also of paramount importance is substantive and demonstrable business and technical writing experience. Proven experience in writing Advanced Planning Documents. Business Function Documents (BFD, Use Case, UML, Specifications, Procedures, User Manuals
Hierarchy of UML Diagrams, shown as a class drawing
In many cases requirements and specifications assist in providing baseline in support of procurement.
Participate and support procurement process and provide guidance to improve agency-wide proposal quality and efficiency. This may include responsibility for the development and periodic revision of modular content (e.g., pursuit resource guides) as directed by the Project Management Office or the Department’s Procurement Office.
Organize material and complete writing assignment according to RFP requirements regarding order, clarity, conciseness, style, and terminology.
Develops proposal process improvements which lead to improved proposal win-rates by evaluating and re-designing processes, approach, and templates which result in change strategy.
Responsible for collaborating with business resources to ensure that testing processes fully validate requirements for the Project.
Participate in functional and acceptance testing through the direction execution of test cases and scripts.
Reviews, analyzes, and evaluates business systems and user needs.
Familiar with relational database concepts, and client-server concepts.
Relies on experience and judgment to plan and accomplish goals.
Performs a variety of complicated tasks.
“ISO/IEC 19501:2005 – Information technology – Open Distributed Processing – Unified Modeling Language (UML) Version 1.4.2”. Iso.org. 2005-04-01. Retrieved 2015-05-07.
ISO/IEC 19505-1:2012 – Information technology – Object Management Group Unified Modeling Language (OMG UML) – Part 1: Infrastructure”. Iso.org. 2012-04-20. Retrieved 2014-04-10.