Tag: stakeholder

Requirements – What’s the Big Deal????

Requirements – What’s the Big Deal???? ArgonDigital - enterprise automation experts

Note: this is an update to this blog originally published in 2012. Preparing for the future A constant throughout the evolution of systems engineering is an ever-increasing complexity of systems which can be observed in terms of the number of system functions, components, and interfaces and their non-linear interactions and emergent properties. Each of these […]

Implementing a Requirements Development and Management Processes

Implementing a Requirements Development and Management Processes ArgonDigital - enterprise automation experts

Note this is an update to this blog originally posted in 2013. A major challenge to implementing the chosen RDM capability for your organization and project is convincing management and co-workers that it is time to implement or perhaps improve your organization’s RDM capabilities and knocking down the walls of resistance.  I have heard many reasons […]

Stakeholders! Why can’t they just tell me exactly what they want?

Stakeholders! Why can’t they just tell me exactly what they want? ArgonDigital - enterprise automation experts

“It takes less time to do something right than to explain why it was done wrong.” –Henry Wadsworth Longfellow  Project teams build software, systems and products for people to use or consume.  So why is it that many project teams don’t seem to like to engage the actual users when coming up with the requirements […]

Agile and Requirement–Driven Product Development

Agile and Requirement–Driven Product Development ArgonDigital - enterprise automation experts

My previous blog described “Requirement-Driven Product Development” (RDPD). One of my readers asked a very important and well-formed question: “Lou, nice article. Are there any specializations to the approach for software systems? Would you say that Scrum process is consistent with RDPD? I expect that everyone agrees that requirements must drive development. The controversy is […]

How to Communicate “Threshold” vs. “Objective” Requirements.

How to Communicate “Threshold” vs. “Objective” Requirements. ArgonDigital - enterprise automation experts

We were recently asked the following question: “For a system that has both “threshold” and “objective” requirements, what is the best way to delineate them? Our initial thought was to use “should”, but then we don’t want to get them confused with non-verifiable design goals.” The answer depends a lot on how you are define […]

Should the “testors” be involved in requirements development?

Should the “testors” be involved in requirements development? ArgonDigital - enterprise automation experts

On more than one occasion, I have been asked about early involvement of the test team.  To paraphrase a most recent question, I was asked:: “I have studied different articles about this new tendency of involving testers earlier in the project, namely during requirements analysis.  This early involvement means that the tester gives input as […]

Why are we doing what we are Doing?

Why are we doing what we are Doing? ArgonDigital - enterprise automation experts

A common problem we see on new projects is people jump into writing requirements without first answering the question “Why are we doing what we are doing?”  Many challenged projects (e.g., over budget, behind schedule, not meeting quality standards) can trace their difficulties to the very beginning of the project where there was a failure […]

Going from system concepts to requirements – Part 1

Going from system concepts to requirements – Part 1 ArgonDigital - enterprise automation experts

Note: This is Part 1 of our discussion concerning going from system concepts to requirements.  Part 1 addresses the basic concepts; Going from system concepts to requirements – Part 2 delves more into the “How” to go from system concepts to requirements. As you know, before writing requirements there is a lot of work that […]

Going from system concepts to requirements – Part 2

Going from system concepts to requirements – Part 2 ArgonDigital - enterprise automation experts

Note: This is part 2 on our discussion concerning going from system concepts to requirements.  Going from system concepts to requirements Part 1 addresses the basic concepts.  Part 2 goes more into the “How” to go from the Column A stakeholder perspective to the Column B system perspective. There are several challenges you need to […]

ConOps vs OpsCon – What’s the Difference?

ConOps vs OpsCon – What’s the Difference? ArgonDigital - enterprise automation experts

We hear this question over and over again.  This topic comes up a lot in our classes where, as part of scope definition, we stress the need to develop and have at least one feasible system concept prior to writing the technical requirements. There are several “standards” (note 1) that profess to define what a […]

Avoid using “be able to” and “be capable of”

Avoid using “be able to” and “be capable of” ArgonDigital - enterprise automation experts

A common issue that frequently comes up is the use of  “The system shall be capable of…..” or “The system shall be able to….” vs. “The system shall …..”  People often ask:  Is there a distinction?  What is wrong with saying “The system shall be able to operate using 28 VDC” vs. “The system shall […]

Controlling and Managing Change

Controlling and Managing Change ArgonDigital - enterprise automation experts

Controlling and managing change is one of the most important tasks for both the Project Manager and Systems Engineer.  Failing to do so often results in massive cost overruns, schedule slips, and failed projects. In the previous blog “Why do my requirements keep changing?”, we talked about why requirements change.  In this blog we discuss […]