ethernautics

IT Solutions Architects and Cyber Security Engineering

Ethernautics, Inc. – Requirements Engineering

Banner-Michael-W-Meissner-Enterprise-Architect

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.

SDLCIn 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 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.

Design Engineering Process

The design process involves the following:

Design Phases 1

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.

Design Phases 2

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.

Requirements Analysis Tasks

  • Eliciting requirements and Recording/Documenting the findings are the primary responsibilities of the Requirements Engineering Function and can usually be found in the project charter or definition. Business process documentation is gathered through Stakeholder Interviews (SME), Policy and Regulation, Market Research. Technical requirements are uncovered by reviewing Product Specifications, Engineering Design Documentation, Performance Requirements, Cyber Requirements, and collaboration with Technical SME. This activity is referred to as requirements gathering.
  • Analyzing Requirements: determine that requirements are clear, concise, complete, consistent and unambiguous, and resolving any apparent conflicts. Requirements should also be analyzed to determine construct-ability and prioritization.
  • Recording requirements: Requirements may be documented in various forms and may be driven by regulatory and organizational requirements, but also is influenced by the type of requirement being engineered (Infrastructure vs. Software) and also engineering and development methods employed. The forms usually including a summary lists, engineering drawings, or process and vendor specifications, natural-language documents, UML, use cases, and user stories.

    Requirements Engineering Skills

    Collaboration

    Interaction with other Phases and Functions is the primary to the success of successful gathering, documenting and implementing requirements.

RA Interactions

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.

SDLC Linear 2

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.

Me & SDLC

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.

RA Interactions Business Facing

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.RA Interactions Operations Facing

Interaction over time

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.

Relativity and the SDLC

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.

Architectures:

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.

Systems Architectures

  • Host
  • Client Server
  • Stand Alone
  • Cloud
  • Virtual
  • SOA
  • Defense in Depth

Defense in Depth - Target

Infrastructure Architectures

Building Architectures

Outside Plant

Design and Development Methods

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.

Me & SDLC

Design and Development Paradigms and Models

  • Software Engineering
    • Waterfall
    • Prototyping
    • Incremental
    • V-Model
    • Dual Vee Model
    • Spiral
    • IID
    • Agile
    • Lean
    • DevOps
  • Systems Engineering
  • Database Engineer
  • Application and Database Security
  • Construction Engineering

Design and Development Methodologies

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.

DESIGN STANDARDS: REQUIREMENTS ANALYSIS, BEST PRACTICES DOCUMENTATION, TRACEABILITY

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.

  • ANSI/TIA/EIA STANDARDS
  • ITIL
  • MasterFormat
  • RUP
  • “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.
  • Requirements Analysis

    Documentation (Technical Writing) and use case

    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).

    Traceability and Test

    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.

    QA

    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.

    Project Management

    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.

    Soft Skills

    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

    • Ability to communicate effectively, verbally and in writing, to interact effectively with internal and external vendors, project team members, management and agency departments, to build relationships and use facilitation skills with both technical and non-technical personnel
    • Ability to write, edit, and prepare graphic presentations of technical information for both technical and business personnel
    • Experience in organizing information in a way that is appropriate for technical explanations without losing sight of the needs and aptitude of the audience
    • Ability to collaborate and coordinate with multiple teams and vendors
    • Ability to work independently and as a member of a team
    • Ability to multitask and prioritize tasks effectively in order to meet deadlines
    • Have proficiency/understanding of the MS SharePoint application
    • Must be intermediate to advance in Microsoft Office (Word, Excel, PowerPoint, Visio) and working with templates and style guidelines for branding consistency
    • Keen attention to detail while maintaining the ability to see the big picture
    • Ability to absorb and retain complex processes
    • Strong language skills
    • Demonstrable understanding of the rules of English grammar and usage
    • Ability to accept changes and constructive criticism in a fast turn-around environment

    Tools

    • Experience with process workflow automation software
      • BizAgi
      • NetCracker
    • Documentation Techniques

UML Class Diagram

Hierarchy of UML Diagrams, shown as a class drawing

  • UML is not a method, it was designed to be compatible with the leading object-oriented software development methods; Booch method, OMT, Objectory, and RUP
  • Most of the technical disciplines (Electrical Engineering, Systems engineering & Network Engineering & Database Engineering) also have a multitude of available tools that include modeling and simulation, requirements analysis and scheduling to manage complexity of their specific functional domain.

Responsibilities

  • Work alongside the Business Analyst/SMEs and technical staff to understand the goals/objectives of the project in order to assist in creating deliverables and supporting project documentation for inclusion in Advanced Planning Documents (APD) and Request for Proposals (RFP)
  • Interview subject-matter experts to understand the processes, technologies, business needs, and other contextual details of a subject-matter domain and to elicit the appropriate technical information to compose high-quality technical write-ups. Drive discussions with project and business teams on proposal “win themes” and other strategic messages and incorporate as appropriate

Requirements Documentation

  • Organize material and complete writing assignment according to organizational requirements, best practices, and methodologies, maintaining order, clarity, conciseness, style, and terminology.
  • Drafts, finalizes edits, standardizes, or modifies materials prepared by other writers.  Coordinates with team leader to meet required deadlines by establishing priorities and target dates for all phases of the project from inception to final delivery.
  • Gathers proposal information by identifying sources of information; coordinating submissions and collections; identifying and communicating risks associated with assigned proposals.
  • Maintains quality results by using templates; following proposal-writing standards including readability, consistency, and tone to ensure quality for all deliverables.
  • 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.
  • Researches a variety of assigned topics and develop writing plans and outlines.
  • Assists in the development of supporting materials (illustrations, tables, etc.). Prepare charts, graphs, or forms.
  • Establishes and maintains electronic and/or hardcopy data library of documents and work order files for documents received for processing. Maintains all final documents in Department databases and repositories.
  • Explain scientific and technical ideas in simple language ensuring technical verbiage is easy to understand by the layperson.
  • Review the final production materials to ensure that message quality, format and content meet the stated objective and are consistent with agency-wide strategy and communication guidelines.
  • Manage and create documentation in an iterative manner; Eliminate reliance on traditional “waterfall” approaches to processes in order to accelerate delivery of written products.
  • Aid in organizing and maintaining the project’s Record Management and Document Control Process. (i.e SharePoint repository).

Support Procurement Process

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.

Support the Testing Process

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.

Required Skill

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.

Specialty Requirements

  • Cyber Security
  • Plant Control (PCS), ICS, SCADA Systems
  • Infrastructure
  • Aircraft/Seacraft/Marina
  • Hardware
  • Medical Health Care

Reference Projects

  • Ethernautics, Inc – Michael W. Meissner: Cyber Security Infrastructure Architect / Digital Engineer (See Here)
  • Ethernautics, Inc. – Meissner Project with Global Telecom Merger (See Here)
  • Ethernautics, Inc. – Meissner Project Telcordia (See Here)
  • Ethernautics, Inc. – Meissner Project with California Water Services Group (See Here)
  • Ethernautics, Inc. – Michael W Meissner: Solutions Architect and Infrastructure Architect (See Here)
  • Ethernautics, Inc. – Meissner: Cyber Security Standards, Best Practices and PRADL for Water Utilities (See Here)
  • Ethernautics, Inc. – Meissner: Cyber Security for National Infrastructure – Water Resources (See Here)
  • Ethernautics, Inc. – Meissner: Cyber Security in National Infrastructure (See Here)
  • Ethernautics, Inc. – Michael W. Meissner Program Management and Project Management Expertise (See Here)
  • Ethernautics, Inc. – BSS – OSS Solutions Architecture (See Here)
  • Ethernautics, Inc. – Structured Cabling Design Standards (See Here)
  • Information Mechanics, Inc. – Meissner Project with Telecommunications Company Inc. (TCI) (See Here)
  • Ethernautics, Inc. – Meissner Project with NetCracker Technologies (See Here)
  • Ethernautics, Inc. – Client Project with Areva, NP at South Texas Project (STP) (See Here)
  • Ethernautics, Inc. – Client Project with CSC at Urenco (See Here)
  • Ethernautics, Inc. – Michael W Meissner: Cyber Security Database Threats (See Here)
  • Glossary of Terms – Cyber Security at Nuclear Power Plants (See Here)

References

“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.

 

 

 

 

 

 

 

 

 

 

 

 

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Information

This entry was posted on February 21, 2016 by in Cyber Security.
%d bloggers like this: