Patterns as Requirement Clusters
Copyright 2006 Robert J. Glushko
Setting the Context
Requirements - and Finding Them
Representing Requirements as Rules
Assignment 6
Any Document Engineering project worth doing will involve some set of document types and information components that take part in some set of business processes
Because "no document (or process) is an island" there will always be some point at which the documents and processes you care about will intersect or overlap with some that that you don't care about
We'll call the Context whatever characteristics of the situation that define what is in or out of scope, inside or outside of the boundary in which our solution has to work
Much of what businesses do for themselves and with other businesses can be described using a small repertoire of supply chain or other business process / transaction patterns
Each of these patterns implies a set of documents and some choreographies of document exchanges
Selecting an appropriate pattern will help expose the information requirements, rules and constraints for our subsequent document analysis and design
Choosing a pattern suggests which document payloads we'll need to find or design and in which business processes we are likely to deploy them
How we describe context influences what patterns we identify and how we apply them
Business processes are the most important context dimensions because they most strongly shape the information requirements
For example, contextualizing a simple procurement pattern to have the seller and buyer in different countries adds new processes and documents
Product Classification
Industry Classification
Geopolitical Classification
Legal or Regulatory Jurisdiction
Business Process Role or Supporting Role
Once a problem or opportunity is defined, any constraints on possible solutions or goals that must be satisfied can be viewed as requirements: conditions that must be met for the solution to be acceptable
Requirements are most often functional: descriptions of what the solution must do or must enable someone to do with it
Other categories of requirements include...
Requirements can be quantitative or qualitative, but in all cases should be verifiable
Requirements do not dictate how the solution is to be achieved – that is the responsibility of design
Occasionally requirements are developed in an extremely rigorous way
Large companies or organizations (example: government, military, General Motors) may conduct a "contract definition phase" or issue a "Request for Information" (RFI) document in which they engage multiple companies or consultants to define a problem and come up with some preliminary solution or design concepts
These requirements may be heavily constrained by legacy technology or processes unique to the customer, which implies that an "engineered to order" solution is required rather than a standard "off the shelf" one
The best ideas then get turned into a "contract specification" or a "Request for Quote" (RFQ) document and companies (usually including those that contributed to it) compete for the right to build the system or supply the goods according to the specification.
Most companies carry out IT planning activities (in software companies these are called "product management" or "product marketing" activities) to define requirements for systems or applications
The results of this activity are recorded in a "Product Requirements Document" or PRD
These requirements are then negotiated with the organization that will design and develop them (engineering or other R&D organization)
Even if what ultimately gets built is less ambitious than what marketing wanted, the requirements specifications can provide a roadmap for future versions or products
Some companies – especially new or undisciplined ones – don't bother with requirements
Many people want to "get on with it" and are biased toward working on the "end product" (doing the programming or implementation activity) rather than working on less tangible intermediate artifacts (like those produced by requirements, analysis, and design activities)
So they don't specify requirements in any rigorous way and no models of information or process are created
However, products or systems built in such an ad hoc manner tend to be difficult to modify when the true requirements become known. And despite what people say they will do, such prototypes are almost never "thrown away" but instead are hacked until they evolve into the "real" product.
Not saying that "prototyping is bad" but "model-guided prototyping" is a lot better
Document Engineering focuses on the requirements for information and process models and by their computer-processable implementations
Requirements for the associated software applications are obviously important, but Document Engineering has nothing special to say about them
But a successful project must also satisfy the latter!
Many of the information requirements in document-intensive contexts are contained in existing documents
There is no sharp line dividing "requirements analysis," in which we get requirements from people, and "document analysis," in which we obtain them from documents.
But it is easier to explain the latter if we begin by discussing the former, treating them as separate activities
Automated information capture -- Eliminate manual entry (or reentry) of information when documents are created, reusing as much as possible from other documents or sources.
Straight-through processing -- Minimize the need for any human intervention as a document flows through some specified processes.
Timeliness -- Make information available to those who need it when it is needed and when promised, and update it promptly when it changes.
Accuracy -- Ensure that every piece of information in a document is correct.
Completeness -- Ensure that a document contains all the information it should or that its recipient (person or application) expects.
Automated validation -- Provide a schema or specification that enables information to be validated.
Interoperability -- Enable information to be used "as is" or via automated transformation by systems or applications other than the one that created it.
Standards compliance -- Conform to regulations or standards for information structure, accessibility, availability, security, and privacy.
Customizability -- Facilitate the internationalization, localization, and subsetting of information.
Usability-- Present information in a format or medium that is easy to use and understand by its intended users.
Identifiability -- Ensure that the design or appearance of a document signals that it comes from our organization or company; also called branding of the information.
Document Engineering often requires deconstructing artifacts then restructuring, repurposing, and re-presenting them; here are categories of relationships between the AS-IS and TO-BE manifestations:
Content integrity – preserve the (important) content of the original document, but not necessarily with the same structure or presentation
Structural fidelity – content integrity with the additional requirement to preserve the structure of the original document
Structural integrity – Structural fidelity and using the same assembly rules (e.g. page boundaries)
Presentation fidelity – Structural integrity with complete preservation of original presentation
Users (there may be multiple classes of users)
Customer
Subject matter experts
Consultants
Technical gatekeeper
Executive project sponsor (funding sponsor)
"Product visionary"
Marketing and sales people who talk with customers
"Seek first to understand, then to be understood")
In "Design for Success" (Bill Rouse [Wiley, 1991]) this is called the "naturalist" phase
A "naturalist" or "anthropologist" studies people or phenomena in their natural surroundings
observes and listens but does not try to influence
...
We also need to take an archaeologist's perspective to discover requirements, but we'll defer that to "Document Analysis"
Most people concede that the "naturalist" perspective is needed if you're designing a new system or a new product (or a new document)
But others will argue that once something exists, upgrades or new versions of it can be designed without a new requirements activity
In "document-intensive" processes (especially those where the documents are paper ones) it is seductively easy to define a requirement of "replacing paper forms with online ones" while otherwise leaving the basic processes the same
Going back to "square one" is desirable, if only to validate existing requirements
If you did your job well in the naturalist phase, you can test your understanding of the requirements by conceptualizing alternative ways to satisfy them and trying to "sell" these to the people giving you the requirements
Rouse calls this the "marketing" phase
Testing your understanding means you won't end up "blaming the victim" for not expressing requirements correctly
Get people's impression of whether your approach would meet the need in an acceptable and usable way
The analyst is the "communication middleman" between the customer and the developer (Wiegers) [and often between different types of customer stakeholders]
The analyst translates technical language into business language and vice versa
An intermediary is necessary because the customer and developer speak different languages
So the analyst needs to be able to speak the language of both the customer and the developer
Solution requirements – the functional, performance, quality attributes
Information or data requirements – what information is needed, what are its datatypes, possible values – the document component model
Document or structure requirements – how is the information organized / assembled / packaged into sets of related information – the document assembly model
Processing and usage requirements – what relationships between documents have a business purpose, what constraints on access or presentation (or on the relationship between logical and presentation models) are mandated by business relationships – process / choreography / orchestration model or adjuncts to document models
Presentation or syntactic requirements – how is the information presented or formatted or rendered – the physical or output model
"Business Rule" is an up and coming buzzword in information systems that is a lot broader than its name might suggest
A Business Rule is a formal or refined statement of an requirement that is expressed in a technology-independent fashion
By capturing requirements as Business Rules we can envision implementing or enforcing them externally from the "generic" aspects of applications rather than scattering them into application code
There are many different schemes for categorizing requirements or business rules.
Most approaches distinguish constraints on content that are represented in data models from constraints on behavior represented in process models
Other schemes distinguish single-item constraints that must always be true from those that reflect the relationship between two or more items or that can change according to a process context
Constraints can also be classified according to the manner in which they are represented and enforced in an implemented application
Rules that Apply to Conceptual Models
Semantic
Structural
Usage
Rules that (Can Also) Apply to Physical Models
Syntactic
Processing
Presentational
Rules that Apply to Instances or Implementations
Content
Assignment 4 - Course Project, ungraded description due 13 March
Assignment 5 - UML, ungraded due 13 March
Assignment 6 - Requirements and Inventory, graded due Wednesday 15 March
Chapter 11 of Document Engineering
Chapter 16 of Document Engineering, 540-554 (Capability Assessment)