Copyright 2003, 2018 Nikolas S. Boyd. Permission is granted to copy this document provided this copyright statement is retained in all copies.
A Conceptual Model for Software Requirements |
Nik Boyd |
Software development is not only technical, but also inherently political. The political and technical relationships inherent in corporate software development organizations will be considered and discussed. A framework and models relating various stakeholders and their knowledge will be offered and some of the usual suspects will be listed, along with their natural areas of competence. Some of the best practices for developing and utilizing their domain knowledge will be listed.
What must be the overall goal of software development? Significant business value consistently delivered. Achieving this ambitious end requires that development activities always keep technology solutions focused on and aligned with business objectives: mission, vision, and human-scale value. Given the formidable forces arrayed against it, how can this goal be accomplished? This paper attempts to offer the beginnings of an answer to this question.
Software development is a knowledge intensive, knowledge-driven activity. But, people are the reservoirs of knowledge needed to develop software, both business knowledge and technical knowledge. So, software development is inherently both technical and political. Successful software development requires effective collaboration between all interested stakeholders throughout an organization during software development projects that impact their interests. But, in order to be effective, stakeholders must share a common understanding of the problem(s) they are trying to solve or resolve.
Without adequate representation, without early and frequent consideration, some stakeholder concerns will not be discovered and weighed, and any solution that results consequently will be inherently incomplete. Several kinds of stakeholders serve as official information sources, especially for software solution requirements. These stakeholders can be grouped according to their collaborative roles, including corporate boards and officers (governors), those who manage business activities (requestors), those who perform business activities (expectors), and the solution developers.
Each group of stakeholders bears responsibility for providing specific kinds of information to the solution development process or for actually implementing a solution. A corporate board governs a business, establishes business direction, defines business policies, and articulates the values, mission, and vision of a business. Corporate officers implement the directives established by the board. Department managers oversee business activities and determine whether and how to improve those activities.
These decisions often include the introduction and improvement (extension and integration) of technical solutions, including custom (or customized) software solutions. Stakeholders directly involved with technical solutions (installers, operators, users, auditors, maintainers) expect these solutions to support and improve the business processes they are required to fulfill. Software developers provide effort estimates and build software components to implement technical solutions, including custom(ized) software applications.
All of these various stakeholders must share information, a common vision and expectations. While direct personal discussions provide the highest bandwidth and deepest understanding of this shared knowledge, some of this knowledge will usually be captured in relatively static forms, including written corporate policies, corporate values, mission and vision statements, descriptions of business activities (as procedures or processes), the requested improvements to business activities, the software features needed to satisfy these requests, and associated project and software solution documentation: installation and configuration guides, user and operator guides, etc.
Each of these documents contributes valuable knowledge to software development efforts. Each document can be viewed as a kind of knowledge base captured in written form. Each knowledge product has a natural technical structure and conceptual dependencies on the antecedent knowledge and people from which it was derived. Thus, subsequent work products (really knowledge products) can and should be traceable to their antecedents and their official sources. So, threads of traceability link together the political (people) and technical (knowledge) aspects of software development, and the relationships between the knowledge products and their sources weave together to form a complex web of solution requirements.
The solution requirements web has an overall structure that radiates outward, expanding from a central hub of governance vision towards technical solution components. Requirements can be discovered anywhere in the web. But, when discovered in the further extent of the web, they need to be aligned with and connected to more central requirements, purposes and objectives along quality lines. This model offers solution requirements engineers a conceptual framework within which to understand and place specific requirements, and a means whereby to align the various kinds of requirements and ensure that they are traceable to a value proposition, and in proper alignment with the business mission and vision.
Vision, mission and values articulate the intended ends of a business and the acceptable means for reaching those ends. Purposes align business activities with the business mission and vision. Business activities fulfill a business purpose and further a business towards its objectives. Business activities often have opportunities for (measurable) improvements. Software solution features support and improve business activities. Dialogs reveal solution features and domain information models. Software components surface dialogs and conduct conversations with software solution users. Solution requirements knowledge and descriptions originate with some official (or unofficial) sources.
The relationships between stakeholders, sources, and their knowledge can be modeled and depicted graphically. The following diagram shows selected, representative portions of such a natural conceptual model. A key to the notation used in this model diagram can be found in Appendix A. Descriptions of the essential model elements can be found in the linked pages, both through the foregoing textual hyperlinks and through links contained in the following model diagram. Each element in the diagram below links to a topic of the same name, with more discussions about the topic and more links to other related topics.
As indicated previously, each stakeholder holds certain interests and quality concerns. The tables following each stakeholder description lists some of the typical stakeholders in each group and some of the kinds of interests and concerns they hold. Review of these lists can be useful when a requirements engineer wants to test whether a set of solution requirements has adequate stakeholder and interest coverage, or whether they are under represented.
While each requirement may appear simple in concept, it will naturally have a complex web of relationships and several measurable and enumerable attributes. The following table lists some of these essential attributes, including basic identification, measurements, elements of the surrounding political web, and status in the development lifecycle.
| Attribute | Description | |
| Identifier | uniquely identifies a requirement within a repository (or a document) | |
| Category | Policy, Purpose, Improvement, Activity, Feature, Dialog, Component | |
| Description | describes the result to be achieved: information to be captured or delivered, activity or quality to be improved | |
| Verification | lists the steps needed to verify that the requirement has been fulfilled | |
| Value | answers why the requirement exists (rationale), indicating: | |
| the need(s) addressed, the benefit(s) offered by addressing the need(s), | ||
| and the ultimate value conferred (esp. if quantifiable as revenues or savings) | ||
| Risks | estimates the impact of failure to deliver: | |
| schedule consequences, financial consequences, | ||
| political consequences, lost opportunity costs, etc. | ||
| Difficulties | considers the likely technical and/or political challenges posed by the requirement, | |
| plus an overall estimate of the level of these challenges, both | ||
| technical: unknown, intractable, hard, moderate, easy, trivial, and | ||
| political: open conflict, irreconcilable differences, negotiable, | ||
| partial agreement, complete agreement | ||
| Effort | estimates of human resources: manpower (man-hour) estimates | |
| Costs | estimates of other resources, esp. if quantifiable as budgets | |
| Stability | estimates the liklihood that the requirement formulation or understanding will change | |
| Priority | often results from a weighted evaluation of the foregoing attributes as ROI | |
| Dependents | identifies which other requirements depend upon this one | |
| Dependencies | identifies the other requirements upon which this one depends | |
| Interests | lists the interested stakeholders along with their interests and concerns | |
| Source | identifies the official source of knowledge regarding this requirement (a person) | |
| Knowledge | indicates the state of knowledge: | |
| identified, formulated, understood, shared, validated | ||
| Status | indicates the lifecycle state of the requirement: | |
| proposed, deferred, cancelled, approved, incorporated, validated | ||
| Dates | discovery date, ..., proposal date, ..., approval date, ..., | |
| incorpoation date, ..., release date | ||
All of these attributes contribute information needed to make requirements manageable, especially with a large backlog of incomplete and unfulfilled requirements. Even on relatively small projects and even with ambitions of agile development processes, having adequate information about requirements helps development activities deliver real value and maximize return on investment. But, the single most important quality supported by these attributes is consistency. To consistently deliver significant business value entails that requirements be manageable, especially when the solutions must be durable, as when they have an anticipated lifespan of many years.
Given the extent to which politics infects the software development process, and the attendant challenges in organizational communication and alignment, perhaps it is not so surprising that attempts to solve enterprise scale problems seldom yield substantive business value. However, there are appropriate techniques for developing each knowledge work product, including the business vision, mission, business activity improvements and opportunities, software solution features, interaction dialogs, and components. This section lists some of the practices that can be used to address each of the various requirements levels, with citations to some of the extant literature for pursuing these practices.
Level 0: Vision, Mission, Values
Vision is all about value: changing the world for the better. Without vision, work is meaningless, boring, passionless drudgery.
Policy Governance® 1, 2 emphasizes ends over means. It guides corporate boards to discover and give voice to humane corporate policies, real vision and mission statements that make a difference, especially through the proper expression of ends and the acceptable means for achieving those ends.
The Cluetrain Manifesto:3 Real vision must be about adding real value and serving the real needs of individuals, not ephemeral "markets." People know what they value and what are their real needs. Just ask them and they'll tell you. Networked markets now meet networked workers in a 24 x 7 global bazaar, people serving and being served directly on an intimate, human level, via intelligent, witty conversations. So, you don't even need to ask people what they need. The conversations are going on right now! Businesses that fail to participate intelligently in these mass conversations will be bypassed by businesses that do. Businesses that "get a clue" will rule.
The Core Protocols4: When teams align their passion with vision, greatness results: innovative products and services, exciting, meaningful work with enthusiastic collaborators. The Core Protocols offer time- and team-proven practices for establishing and maintaining effective, creative work(ing) conversations for teams, especially those that produce intellectual properties. These protocols engage team participants and harness their personal intelligence, presence, integrity, needs, and passion. Through consistent alignment of their passions with their shared vision, the protocols help a team achieve greatness.
Level 1: Business Activity
Business activities derive from the policies and procedures determined by ends and acceptable means. Business activities (should) add (or conserve) value. Activities that don't add (significant) value should be eliminated (or diminished) in favor of those that do.
Business activities cross organizational boundaries, so a comprehensive understanding of them and the impacts of any process changes naturally require the participation of the people involved, i.e., those who have the organizational knowledge and who best understand the processes.
Business Process (Re)Engineering:5, 6 Businesses cannot be re-engineered without first being engineered. However, business engineering and re-engineering can proceed concurrently, especially on the basis of continuous (gradual) improvement.
Convergent Engineering:7 Modern businesses are driven by information and technology. To engineer a comprehensive and adaptive business solution, business engineering and software engineering need to be coupled and need to converge. Business process slices must be integrated across work groups, disciplines and organizational boundaries to produce convergent models and views of enterprise business elements, activities and quality concerns.
Business Technology Management:8 To consistently deliver significant business value, technology investments must be aligned with business needs via portfolios. Standardized technologies and architectures should be adopted whereever and whenever possible to reduce construction and maintenance costs.
Enduring Business Themes:9-12 Quality concerns are the most durable business themes. Activities aligned with these themes are the most durable processes. Business elements related by these activities often have stable surfaces, but may be replaceable. Technical solution components often have both changing surfaces and frequent replacements. Business architectures informed by these principles maximize stability where the opportunities for stability are greatest.
Level 2: Activity Improvement
Activities offer opportunities for improvements, often via the removal of bottlenecks, automation and information systems.
Total Quality Management:13 Workflow analysis discovers and models how work products and information flow throughout the enterprise. But, workers (esp. knowledge workers) usually know what's broken in their jobs. Just ask them and they'll (often eagerly) tell you how to fix it. Organize people into cross-functional teams. Educate them and empower them to (re)solve their productivity and quality problems.
Goal, Question, Metric (GQM) Approach:14 Activities and work products must be (or must be made) measurable in order for improvements to be measurable. Discovering appropriate measures supports the establishment of qualitative and quantitative (measurable) goals.
Measurement Theory:15 Measures have metrics. The choice of measurements must match the quality concerns they are intended to monitor. Measurement has associated (often significant) collection and analysis costs. So, collection, analysis and reporting must be automated as much as possible.
Business Intelligence:16 Activity and product measures and metrics determine the requisite instrumentation needed for collecting measurements. Enterprise instrumentation surfaces operational performance and quality measurements to management as business intelligence. Management uses business intelligence to guide and improve activities.
Quality Alignment:17 Business activity planning usually involves establishing a set of objectives and priorities, as well as the criteria used to measure progress against those objectives and to determine ultimate success in achieving them. Business value can often be expressed in terms of specific improvements in product, service, and process qualities based on measurable changes in the levels of these qualities.
Level 3: Solution Feature
Activities have goals, ends toward which the activities are directed. Activities operate on the attributes of objects, resulting in state changes. Activities are performed by individuals with roles, which have responsibilities and permissions. Activities can be decomposed into tasks, which can be further decomposed into (permitted) operations.
Natural Conceptual Modeling18 with EDUCE19 extracts and organizes essential domain and usage concepts from natural language requirements and problem descriptions. When applied systematically, EDUCE consistently produces high quality domain vocabularies, including candidate objects (and classes) and client valued functions and qualities. These can then be organized in a variety of ways: natural conceptual models, domain models, object-oriented analysis and design models, feature definitions, business intelligence instrumentation, etc.
Natural Language Modeling.20 extracts and organizes facts, fact types, and relations from natural language requirements and problem descriptions. The resulting models provide precise information models useful for information designs, especially for relational and object-oriented database schemas.
Level 4: Interaction Dialog
Interaction dialogs serve as the boundary between a system and its users. Dialogs reveal solution information models and expose system operations. Operational analysis determines what are the system operations, their inputs, preconditions and results (postconditions).
Usage-Centered Design21 translates feature requests, usage needs, and operational modalities into interaction dialogs: essential use cases, goal oriented use cases, and fully dressed usage scenarios.
Use Cases22 describe interactions between participants at several distinct levels, including a business and its customers, a business and its partners, the employees of a business, the users of information systems, the components of a software solution. While use cases may be used to capture interactions on all of these levels, they are primarily oriented toward (and take their name from) user interactions with information systems.
Level 5: Solution Component
Software components are deliverable units of work, functionality and quality. Components are assembled into subsystems, systems and applications. Components reveal their functionality through interfaces, some of these include human interfaces (via dialogs).
Responsibility-Driven Design23, 24 uses anthropomorphism and interpersonal communication as primary metaphors for object-oriented designs. Responsibility-driven object-oriented design assigns responsibility for system operations, quality fulfillment, knowledge and behavior to software solution components.
Design Patterns25, 26, 27 describe known solutions to frequently encountered design problems in the context of their appearance. These include solutions to various constructive, structural, behavioral, and qualitative problems.
Natural Naming28 suggests that using complete and natural names for software elements, components and composites increases their intelligibility and long term maintainability. It also offers specific recommendations for naming software elements, components and composites.
Level 6: Development Project
Projects organize developers and their efforts to construct and/or evolve software components.
Feature Driven Development29 organizes solution development activities on the basis of client-valued functions (aka features) and their relative value-based priorities.
Scrum30 organizes teams with short delivery cycles. Scrum focuses on developer effectiveness. Short, daily, stand-up status meetings systematically identify obstacles to progress that need to be resolved by the project manager(s). This allows the developers to focus solely on activities that deliver value.
eXtreme Programming31 embraces the challenge of delivering perceivable business value in the face of changing requirements. A suite of (often misunderstood and sometimes controversial) development practices produces a synergy of team effectiveness, productivity and quality.
Crystal Methodologies32 offers a family of development methodologies that address the needs of various kinds of development projects. Each of these methodologies focuses on the people involved in the project and their communications with each other. The Crystal Methodologies don't offer parts that need assembly, but rather prepackaged assemblies from which a specific project may select and then tune based on its specific needs and characteristics.
Thanks to Elemer Magaziner of Project Linguistics International for introducing me to some of the concepts discussed in this paper. I have extended some of them beyond their original shape. So, any distortions are entirely my own.
Policy Governance® is a registered service mark of John Carver.
Natural conceptual models show relationships between conceptual elements from a natural language. Objects are depicted using rectangles. Verbs are depicted using connectors with solid arrowheads. So, verb targets are the direct objects of normalized sentences. Prepositions are depicted using connectors with open arrowheads. So, prepositional targets are the indirect objects of normalized sentences. The cardinality of a target element is indicated by the number of arrowheads on the connector. Singularity is depicted with a single arrowhead, while multiplicity is depicted with multiple arrowheads.
