A dissertation that has typos has too many words.
A dissertation that has typos but makes sense nevertheless is not a dissertation worth writing.
If writing is a muscle that can be trained to improve one's writing, don't forget to train both the left and right parts of the brain, lest they grow uneven.
Suppose that in 2001, seventeen corporate finance professionals came together at a ski lodge, and wrote a document called "Manifesto for Agile Corporate Finance", and one of the values promoted is "Cash on hand over receivables" (analogous to 'working software over comprehensive documentation).
How bizarre would it be if the values espoused in their manifesto then gets used as bedrock foundations for: the right way to build software, run projects, and a host of other activities unrelated to corporate finance?
I also wonder if everyone would be calling it the "Agile Manifesto" for short, omitting the "for Corporate Finance", thus obscuring its intended domain.
Whenever someone refers to the "principles of Agile" and claims these principles are found in the Agile Manifesto, always remember the manifesto is called "Manifesto for Agile Software Development".
It's not "Manifesto for Agile Anything". It's not "Manifesto for Agile Marketing". It's not "Manifesto for Business Agility". It's not "Manifesto for Agile Project Management"
It's a manifesto for agile software development.
The manifesto was written by software developers to promote better, faster, more enjoyable, higher quality software and software development experience.
Busy working on a new product: Voicemail for doors.
If someone knocks on your door (or rings the doorbell), it prompts: "Hi, I can't come to the door right now. Tell me who you are and why you're here, and I'll open the door as soon as I can. <beep>"
In the field of systems development, we distinguish between different kinds of requirements, such as top level requirements, business requirements, user requirements, and system requirements.
Business requirements refer to the overarching needs and constraints imposed by an organisation's stakeholders on the solutions to a problem. They delineate the range of acceptable solutions to the problem, but without going too much into the solution. User requirements in contrast dictate needs relating to how the solution will be operated, maintained, and used.
Business requirements can derive from organisational policies, strategies, business case, and a range of other sources.
Examples of business requirements are:
Buede, Dennis M. The Engineering Design of Systems: Models and Methods, 3rd Edition. John Wiley & Sons, 2016.
Strong focus on function analysis and decision analysis. Good introduction to IDEF0.
Chapman, William L., Terry Bahill, and A. Wayne Wymore. Engineering Modeling and Design. Boca Raton, FL: CRC Press, Taylor & Francis Group, 2019.
Forsberg, Kevin, Hal Mooz, and Howard Cotterman. Visualizing Project Management: Models and Frameworks for Mastering Complex Systems. Hoboken, NJ: J. Wiley, 2005.
The rare project management book that gives emphasis on the critical importance of systems engineering.
Gibson, John E., William T. Scherer, William F. Gibson, and Michael C. Smith. How to Do Systems Analysis: Primer and Casebook. Hoboken, NJ: Wiley, 2017.
Teaches systems analysis (systems decision making) rather than systems engineering. Systems analysis is an essential practice in systems engineering. Bahill's book on trade-off analysis is another one of few books on the subject.
Hitchins, Derek K. Systems Engineering a 21st Century Systems Methodology. Chichester, West Sussex, England: John Wiley, 2007.
Kossiakoff, Alexander, Steven M. Biemer, Samuel J. Seymour, and David A. Flanigan. Systems Engineering: Principles and Practice. Hoboken, NJ: John Wiley & Sons, Inc., 2020.
James, Martin. N. System Engineering Guide Book. Springer, 1997.
Rechtin, Eberhardt. Systems Architecting: Creating and Building Complex Systems. Englewood Cliffs, N.J: Prentice Hall, 1991.
Sage, Andrew P., and Andrew P. Sage. Systems Engineering. New York: J. Wiley & Sons, 1992.
Stevens, Richard J. Systems Engineering: Coping with Complexity. London: Pearson/Prentice Hall, 1998.
Walden, David D., Garry J. Roedler, Kevin Forsberg, R. Douglas Hamelin, and Thomas M. Shortell. INCOSE Systems Engineering Handbook: a Guide for System Life Cycle Processes and Activities. Hoboken, NJ: Wiley, 2015.
Wymore, A. Wayne. Model-Based Systems Engineering: an Introduction to the Mathematical Theory of Discrete Systems and the Tricotyledon Theory of System Design. Boca Raton: CRC Press, 1993.
What are the user requirements for using an ATM? The most obvious ones are: ability to withdraw cash, ability to check account balance, ability to make deposits.
But how about others: ability to retrieve all the coins and cash in the ATM, ability to unjam the ATM if things get stuck, ability to physically move the ATM?
They are not requirements of the bank's customers, but they all valid user requirements. The user requirements depend on who the users are.
To build a successful systems, it's necessary to identify who the users of the system are. The 'who' does not mean specific persons, but categories (or types) of users. For an ATM, these can include: the paying stakeholder, bank customers, customers of other banks with whom the ATM's bank has arrangements with, bank personnel who need to manage the ATM, security personnel, network staff who need to ensure the ATM is connected, back office bank staff who need to analyse and report on data about ATM usage, and so on.
It's clear that if we miss one of the categories of users, we will be unlikely to have miraculously provided system functionality that satisfies their needs.
One challenge to identify categories of users occurs when we are building new systems that are not merely upgrade of existing systems. In this case, there are currently no existing users. The categories of users would need to be identified. Other sources, such as the concept of operations, or the operating model are sources of an initial set of users.
Does your system development process include a rigorous identification of the system users?
References:
Stevens, R. J. (1998). Systems engineering: Coping with complexity. London: Pearson/Prentice Hall.
The company DeepLearning.AI offers an online course called "ChatGPT Prompt Engineering for Developers" . The course is available f...
