Software Requirements

Nik’s Papers

A Conceptual Model for Software Requirements

Abstract

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 better/best practices for developing and utilizing their domain knowledge will be listed.

Note: There are lots of links scattered through this paper. Many/most of these links permit discovery of discussions about associated ideas, which form a complex web of interlocking related concepts.

Introduction

What must be the overall mission 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.

Significant business value consistently delivered.

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 stakeholders must contribute and collaborate.

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.

Software Requirements: A Web of Knowledge and Politics

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.

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.

Figure 1. Software Requirements Knowledge Web

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 web extents, 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.

Software Requirements: A Conceptual Model

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 (and some 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.

Figure 2. Software Requirements Conceptual Model

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.

Knowledge Levels and Better/Best Practices

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 Protocols:4 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 Modeling20 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 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.

Domain-Driven Design33 provides a cohesive set of conversational patterns that embed domain terminology into the software systems that we build. DDD stresses doing this in the software, and evolving the models during the life of the software product.

Level 6: Development Project

Projects organize developers and their efforts to construct and/or evolve software components. The efforts of the various stakeholders engaged in solution design and development need to be managed. Especially on larger projects, these efforts can benefit with guidance from requirements engineering.

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.

References

  1. John Carver, Miriam M. Carver. The Basic Principles of Policy Governance. Jossey-Bass Publishers, 1996. ISBN 0-787-902969.
  2. John Carver. Creating a Mission Statement that Makes a Difference. Jossey-Bass Publishers, 1996. ISBN 0-787-903027.
  3. Rick Levine, Chistopher Locke, Doc Searls, David Weinberger. The Cluetrain Manifesto. Perseus Books, 2000. ISBN 0-738-20244-4.
  4. Jim McCarthy, Michelle McCarthy. Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision. Addison-Wesley Publishing, Inc., 2001. ISBN 0-201-60456-6.
  5. Reengineering Resource Center, http://www.reengineering.com/
  6. Workflow and Reengineering International Association, http://www.waria.com/
  7. David Taylor. Business Engineering with Object Technology, John Wiley & Sons, Inc., 1995. ISBN 0-471-04521-7.
  8. Faisal Hoque. The Alignment Effect: How to Get Real Business Value Out of Technology. Financial Times Prentice Hall, 2002. ISBN 0-13-044939-3.
  9. Marshall Cline, Mike Girou. Enduring Business Themes. Communications of the ACM 43(5), May 2000.
  10. Mohamed E. Fayad, Adam Altman. An Introduction to Software Stability. Communications of the ACM 44(9), Sep. 2001.
  11. Mohamed E. Fayad. Accomplishing Software Stability. Communications of the ACM 45(1), Jan. 2002.
  12. Mohamed E. Fayad. How to Deal with Software Stability. Communications of the ACM 45(4), Apr. 2002.
  13. TQM Resources. http://www.gslis.utexas.edu/~rpollock/tqm.html
  14. Victor Basili, Gianluigi Caldiera, Dieter Rombach. The Goal Question Metric Paradigm. Encyclopedia of Software Engineering. John Wiley & Sons, Inc., 2001. ISBN 0-471-37737-6.
  15. Scott Whitmire. Object-Oriented Design Measurement. John Wiley & Sons, Inc., 1997. ISBN 0-471-13417-1.
  16. Business Intelligence. http://businessintelligence.ittoolbox.com/
  17. Nik Boyd. Quality Alignment and Quality Inventories.
  18. Nik Boyd. Using Natural Language in Software Development. Journal of Object-Oriented Programming 11(9), Feb. 1999.
  19. Nik Boyd. EDUCE: Essential Domain + Usage Concept Extraction.
  20. Naural Language Modeling. http://www.sharp-informatics.com/
  21. Larry Constantine, Lucy Lockwood. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. Addison-Wesley Publishing, Inc., 1999. ISBN 0-201-92478-1.
  22. Alistair Cockburn. Writing Effective Use Cases. Addison-Wesley Publishing, Inc., 2000. ISBN 0-201-702258.
  23. Rebecca Wirfs-Brock, Brian Wilkerson, Lauren Wiener. Designing Object-Oriented Software. Prentice Hall, 1990. ISBN 0-136-29825-7.
  24. Kent Beck, Ward Cunningham. A Laboratory for Teaching Object-Oriented Thinking. OOPSLA 1989 Conference Proceedings. ACM SIGPLAN Notices 24(10), 1989. ISBN 0-897-91333-7.
  25. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Publishing, Inc., 1995.
  26. Patterns Home Page. http://hillside.net/patterns/
  27. Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley Publishing, Inc., 1995. ISBN 0-201-42294-8.
  28. Kari Laitinen. Natural Naming in Software Development and Maintenance. VTT Publications 243. Technical Research Centre of Finland, Julkaisija-Utgivare, 1995. ISBN 9-513-84781-0.
  29. Feature Driven Development, http://www.featuredrivendevelopment.com/
  30. Scrum. http://www.controlchaos.com/
  31. eXtreme Programming. http://www.extremeprogramming.org/
  32. Crystal Methodologies. http://alistair.cockburn.us/
  33. Eric Evans. Domain-Driven Design. Addison-Wesley Professional, 2003. ISBN 978-0321125217.

Acknowledgements

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.

Appendix A. Natural Conceptual Modeling Notation

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.

Verb targets are the direct objects of normalized sentences. Prepositions are depicted using connectors with open arrowheads. 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.