Synopsis
As far as systems engineering is concerned, the aim of a feasibility study is to verify that a business solution can be supported by a system architecture (requirements feasibility) subject to some agreed technical and budgetary constraints (engineering feasibility).
Where to Begin
A feasibility study is based on the implicit assumption of slack architecture capabilities. But since capabilities are set with regard to several dimensions, architectures boundaries cannot be taken for granted and decisions may even entail some arbitrage between business requirements and engineering constraints.
Using the well-known distinction between roles (who), activities (how), locations (where), control (when), and contents (what), feasibility should be considered for supporting functionalities (between business processes and systems) and implementation (between functionalities and platforms):
Depending on priorities, feasibility considerations could look from three perspectives:
- Focusing on system functionalities (e.g with use cases) implies that system boundaries are already identified and that the business logic will be defined along with users’ interfaces.
- Starting with business requirements puts business domains and logic on the driving seat, making room for variations in system functionalities and boundaries .
- Operational requirements (physical environments, events, and processes execution) put the emphasis on a mix of business processes and quality of service, thus making software functionalities a dependent variable.
In any case a distinction should be made between requirements and engineering feasibility, the former set with regard to architecture capabilities, the latter with regard to development resources and budget constraints.
Requirements Feasibility & Architecture Capabilities
Functional capabilities are defined at system boundaries and if all feasibility options are to be properly explored, architectures capabilities must be understood as a trade-off between the five intrinsic factors e.g:
- Security (entry points) and confidentiality (domains).
- Compliance with regulatory constraints (domains) and flexibility (activities).
- Reliability (processes) and interoperability (locations).
Feasible options could then be figured out by points set within the capabilities pentagon. Given metrics on functional requirements, their feasibility under the non functional constraints could be assessed with regard to cross capabilities. And since the same five core capabilities can be consistently defined across enterprise, systems, and platforms layers, requirements feasibility could be assessed without prejudging architecture decisions.
Business Requirements & Architecture Capabilities
One step further, the feasibility of business and operational objectives (the “Why” of the Zachman framework) can be more easily assessed if set on the outer range and mapped to architecture capabilities.
Engineering Feasibility & ROI
Finally, the feasibility of business and functional requirements under the constraints set by non functional requirements has to be translated in terms of ROI, and for that purpose the business value has to be compared to the cost of engineering the solution given the resources (people and tools), technical requirements, and budgetary constraints.
That where the transparency and traceability of capabilities across layers may be especially useful when alternatives and priorities are to be considered mixing functionalities, engineering outlays, and operational costs.
I’ve been googling the internet for some related information, but haven’t found anything as good
as what you have here. I must say i, need to improve my Tumblr layout.
What do you use here?
Putchawn,
Looking for consistency of definitions across standards is like trying to ground a rainbow. Definitions are symbolic tools designed on purpose and their validity should be assessed accordingly.
https://caminao.wordpress.com/2014/06/05/fiddling-definitions/
The definitions I cited are valid and more useful in the contexts we are dealing with (BA, RE, Software Engineering and IT) than some of your definitions for the reasons given both in the definitions and explanations and my comments.
If the same term is used or expected to be used even in different contexts, the limits to which the meaning may vary should also be derived from the definition. Otherwise, multiple incompatible and even conflicting interpretations would be possible defeating the purpose of communication.
One may still question and improve the definitions (the cited definitions of “architecture” and “feasibility study” have emerged after due evaluation and assessment) but multiple inconsistent definitions cannot coexist in selected domains of discourse.
PVN, 04MAY15
“You seem to imply that solution, architecture and design are very close if not interchangeable.” On the contrary, see for instance:
https://caminao.wordpress.com/overview/thread-ea/
What would be the point of a feasibility study if all requirements were assumed feasible without further investigation ?
Remy:
Architecture:
The definition you cited at thread-ea of “architecture” is not consistent with ISO / IEEE definition. Collection or structured collection will just be a “collection” but not architecture.
———————
feasibility study
noun
1. a study designed to determine the practicability of *a system or plan*
Collins English Dictionary – Complete & Unabridged 2012 Digital Edition
© William Collins Sons & Co. Ltd. 1979, 1986 © HarperCollins
Publishers 1998, 2000, 2003, 2005, 2006, 2007, 2009, 2012
Cite This Source
http://dictionary.reference.com/browse/feasibility%20study?s=t
================
Feasibility of achieving anything is always with respect to some specific stated or known class of methods implied. There are many factors that determine the feasibility of a plan or system. Merely describing and elaborating requirements is NOT a feasibility study.
It is wrong to assume or reject feasibility of a requirement without a study of what methods are known to have met or have failed to meet the requirements. Requirements by themselves are neither feasible nor infeasible…..they are just requirements or needs!
PVN 03MAY15
Remy:
These are general remarks:
AA Architecture
According to http://www.iso-architecture.org/ieee-1471/defining-architecture.html
3.2 architecture is:
⟨system⟩ fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution
This is supported by examples, explanation and reasoning which I found are comprehensive and convincing. This definition emerged after more than two decades of many tentative and unsatisfactory definitions of software architecture. This definition is certain and clear about “architecture” and its applicability in multiple fields.
Thus “architecture” is about principles and style which are independent of the purpose of application or any specific design to meet the requirements. This is the reason why a church, an airport and .a hospital may have the same architecture but serve almost mutually exclusive purposes.
You seem to imply that solution, architecture and design are very close if not interchangeable. IMO that is not valid.
BB Feasibility
It is not clear what you imply by “system architecture (requirements feasibility)”. Do you consider them to be interchangeable?
Furthermore “requirements feasibility” seems to be misleading if it implies that some requirements are feasible and some are not.
Feasibility is applied to proposed solution or design or plan of doing something but NOT to a need or requirement. Solutions may be known or unknown (to be invented) and one may talk of feasibility, economy, effectiveness, efficiency of solutions but NOT of requirements.
CC Without clarity on AA and BB the message of this article (and possibly others cited) may not be useful.