-
When Reality Hits - Project Managers Roll With It
February 11, 2012
-
When IT Is Your Company’s “Piggy Bank”
February 10, 2012
-
4 Key Things a Project Manager Must Do
February 10, 2012
-
Essential Project Management
February 10, 2012
-
8 Traits of Top Project Managers - Part 1
February 9, 2012
-
Agile Project Management - Engaging Your Customer!
February 9, 2012
-
9 Tips to Avoid Traps in Project Planning
February 9, 2012
-
Why Projects Succeed - Executive Sponsorship
February 8, 2012
-
On Customer Participation in Agile Projects
February 8, 2012
-
A Project Charter for Lazy Teams
February 8, 2012
Making Structured Analysis Your Foundation for Managing Requirements
February 1, 2010 | Author: PM Hut | Filed under: Requirements Management
Making Structured Analysis Your Foundation for Managing Requirements
By Chuck Tryon
For many professionals, Structured Systems Analysis is a modeling discipline for documenting software requirements prior to purchase or construction of a technology based product. While this process modeling method is commonly used for such a purpose, the true intent of Structured Analysis is far more expansive. Since the mid 1980s, the Data Flow Diagrams, Mini-Specifications and Data Dictionary components have been targeted toward creating rigorous, traceable models of pure business requirements. The models of Structured Analysis provide today’s most complete strategy available for collecting, capturing and managing business requirements.
Emphasis on Business Requirements
From the earliest understanding of Structured Analysis, systems analysts and business analysts have created models of what a business must accomplish instead of focusing on how the business solution has or will be performed.
This true analysis view has always been intended to distinguish between essential requirements and other requirements based on organizations, locations, staffing or technology. Such a distinction highlights the differences between the analysis of business requirements and the design of a one or more solutions for the business requirements.
The identification and use of Business Events helps modelers identify the true reason for business requirements and then organize business processes to respond directly and completely to these events.
The clarity and simplicity of resulting models has proven useful for end customer review and direct participation.
Rigorous Models
While Structured Analysis may be applied as a loose, note-taking technique, the proper use of the method is as a rigorous, fully defined model for business requirements.
Rigor may be achieved by…
- Using the modeling techniques completely and consistently.
- Creating all components of the Structured Analysis model (Data Flow Diagram, Mini-Specifications and Data Dictionary).
- Evaluating the individual components of the model using known criteria for morphology, names, content and balancing.
- Evaluating the integration of model components by cross-checking related information.
- Submitting all models for peer review.
Data Model Integration
For any new solution to work accurately in either an automated or manual environment, there must be a tight integration between the business processes requirements and business data requirements. The definition of business entities, attributes, relationships and rules are the domain of a data modeling discipline and a resultant Logical Data Model. Once the essential requirements for business processes are collected around specific Business Events, the associated policy statements may be validated with the corresponding Logical Data Model. This mapping insures that process requirements are consistent with the data definitions prior to any design effort.
Automated Tool Support
The models of Structured Analysis have been targeted by numerous Computer Aided Systems Engineering tools. These CASE tools are expensive and typically considered difficult to use. An easier (though less precise) method for capturing these models may be found on standard workstation desktop software products such as Microsoft Word, Visio and Adobe Acrobat. The components of the models may be linked internally using hyperlinks or bookmarks for easy review. The models may also be stored electronically and then accessed by other members of the business. These models become documentation for future modification and enhancement.
Traceable Models
The greatest strength of Structured Analysis is that it is a true analysis method. Because it focuses the analysts on pure business requirements and avoids solution bias, the resulting models may be used as the foundation for ANY new automated OR manual solution. This makes the Structured Analysis models valid for an integrated solution using elements of main-frame, PC, browser-based, procedural language, HTML or object oriented technologies. In fact, the same business requirements from Structured Analysis may be used to launch multiple, simultaneous solutions using various application architectures.
Solid Beginning Point
When Tom DeMarco first defined Structured Analysis in the 1970s, it was introduced as a very simple modeling method of business realities. Beginning with the work by Steve McMenamin and John Palmer (Essential Systems Analysis) in the early 1980s, supported with the seminar work by Chuck Tryon (Yourdon and Tryon and Associates), techniques were defined to create the Essential Process Model using Business Events. This approach begins with a Current Physical (“as is”) Model of an existing set of business processes that may be validated with end customers and other subject matter experts.
Process Mining
The models are then expanded and examined to find obsolete, unused or invalid requirements that have become attached to true business requirements. The essential business requirements are then mined from this initial, verified understanding of the business. Ultimately, the Essential Process Model is updated with new or revised business requirements that have been defined by the customer during the analysis process.
Open Options
It is important to note that the analysis effort has reached this point…
- Allowing the analysis team to discover and synthesize business requirements from the most trusted source, the end customer.
- Encouraging the end customer to consider and validate future needs as they are confirming known requirements for the current business system.
- Without any bias from former or future solutions.
- Without any commitments required concerning technology acquisition, product purchase, out-sourcing or custom construction. All options remain open with no wasted effort.
Direct Model Use
The products of the Essential Process Model may then be used directly to evaluate various high-level solution options that might satisfy the implementation needs of the end customer. Systems analysts and their design counterparts define a Domain of Automation by considering which essential components (processes, data flows and data stores) will or will not be automated. Once this decision is marked on the Essential Process DFDs, Mini-Specs are then divided along automation and non-automation boundaries.
Anywhere a future automated component must interact with a non-automated element of the model, an interface between them is noted and defined. This provides a powerful and complete process for interface location and definition.
An identical process may be used to show the solution impact of pre-selected software products. Needed revisions and procedural adjustments may be considered for the purchased products.
Interface Design
Because the true solution nature of the eventual software product cannot be know at the beginning of most projects, it is usually advisable to make the Domain of Study for a project larger than any intended Domain of Automation. This will allow the analysis/design team to identify the most effective interface locations, format and content. This also allows consideration of how these new interfaces and automation will impact the non-automated portions of the business.
Multiple New Solutions
Once the Essential Process Model has been “marked up” showing the impact of a specific application architecture, a New Physical (“to be”) Model is created showing the full nature of business requirements that will be part of an automated solution. This model may be used as the basis for an outsourced solution or for internal custom creation. Internal design methods must now be used to transition these automated components through a technical “blueprinting” process prior to construction.
Full Traceability
The Structured Analysis models allow us to trace business requirements from their original source to physical software products because…
- Current Physical Models are created from information supplied by end customers, subject matter experts and real-life business components.
- Current Physical Models are validated with the source of the requirements.
- Business Events are identified by examining how the business interacts beyond project boundaries (terminators).
- Essential requirements are collected around specific Business Events.
- Business Event responses are collected into the Essential Process Model.
- Essential Process Models are mined directly from the Current Physical Models.
- New or revised business requirements are added directly to the Essential Process Model.
- The Essential Process Model may be validated with Logical Data Models for completeness and consistency.
- Multiple future automation options may be displayed tangibly on the Essential Process Model.
- New Physical Models are constructed showing the precise boundaries and interfaces for all automated components.
- Specific design units are identified and transitioned into internal design.
- Internal design products are used to guide the creation of software products.
It is also possible to trace the Business Events of the Essential Process Model upward to well-defined organizational goals and strategies. For this to occur, great precision and rigor must be applied to the definition of the high-level business directions.
Final Observations
No other method for defining business processes provides so clear and complete a discipline as Structured Analysis. Current day Structured Analysis is the result of over 40 years of use and refinement. Because it is a proven partner to software development, the products of Structured Analysis provides specifications that are complete and detailed.
The ability to transition from one model type to the next establishes a known path that is efficient and traceable.
There are numerous short-cut opportunities for the experienced practitioner. Multiple strategies may be employed to focus exclusively on isolated portions of an enterprise or cycle through a total development effort.
Structured Analysis delivers a specification processes that is complete, stable, repeatable and consistent across projects and organizations. It provides an early anchor for managing requirements.
Chuck Tryon is a nationally respected educator and popular symposium speaker. He founded Tryon and Associates in 1986 to provide seminar training and consulting that helps organizations and individuals develop predictable and repeatable approaches to modern project management, knowledge management and business requirements. The strategies presented in Mr. Tryon’s seminars are used by thousands of professionals in hundreds of organizations across the United States, Europe and Canada. His client list includes many top 100 companies.
Chuck has authored 10 multi-day seminars and is working on several new writing projects. He is a frequent speaker at Project Management Institute meetings symposiums across the country. Chuck also serves as the coordinator and moderator for the annual Knowledge and Project Management Symposium (www.kipanet.org) that is held each August in Tulsa.
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.
- Agile Project Management
- Ask the Hut
- Certification
- Change Management
- Communications Management
- Computer Based Information Systems
- Concepts
- Corporate Transformation
- Cost Management
- Critical Chain Project Management
- Delegation
- History
- HR Management
- Implementing Project Management
- Integration Management
- Lessons Learned
- Management
- Miscellaneous
- People Issues
- PMBOK
- PRINCE2
- Procurement Management
- Program Management
- Project Lifecycle Phases
- Project Management Advantages
- Project Management Advantages
- Project Management as a Career
- Project Management Best Practices
- Project Management Charts
- Project Management Definitions
- Project Management Ethics
- Project Management for Beginners
- Project Management Guides
- Project Management Musings
- Project Management Office
- Project Management Proposals
- Project Management Templates
- Project Portfolio Management
- Project Workforce Management
- Quality Management
- Requirements Management
- Risk Management
- Scheduling
- Scope Management
- SCRUM
- Soft Management
- Time Management
- Training
- Uncategorized
1 person has left a comment
Great to hear of someone else using Yourdon & DeMarco’s techniques for generic process modeling beyond SW. I often disguise my use of it by using rectangular boxes vs bubbles to avoid domain objections.
Use of DFDs also ties in very well with the latest Lean process methodologies as any WIP or inventory become readily apparent as unnecessary stores on the diagrams.
As for modeling tools, there are several options in the marketplace today that start at $100 - $200, and have free trial SW downloads for evaluation. I think you’ll find their built-in leveling and consistency checking a useful addition to just visual rendering via MSWord, etc.