h a l f b a k e r yLeft for Bread
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
DOORS and ComplyPro are great at managing
requirements. Essentially a database and a web interface
to collect together system requirements and link to V&V
evidence.
But engineers and subject-matter experts are reluctant
to
use them, because they aren’t conducive to flowing
technical prose.
And they don’t handle images, diagrams
and tables well. So someone (usually the requirements
manager) ends up cutting and pasting word documents
into
DOORS, and the engineers (from that point forward)
deny
any responsibility for the resulting system requirement
specification.
But the advantages of a formal requirements
management
system are structure and traceability.
I propose a tool that looks like a text-creation
application,
but has implicit structure and prompts the author to link
each paragraph of text. So every paragraph is indexed,
and
the creator is asked a few questions to categorise the
text.
Also provides a stakeholder-shared “discuss” to identify
priorities, and better linking to supporting evidence.
And recursive document references (i.e. not just “this
document refers to this other document” but “this other
document refers to this clause here, so if you change it,
it
will have a knock-on effect”
(?) Trivial pursuit
https://en.wikipedi...wiki/Trivial_Pursui
A great way of making money if you are blessed with a good memory for facts. [8th of 7, Oct 01 2019]
Pattern Language
https://books.googl...tml?id=hwAHmktpk5IC
Requirements written as patterns. [Frankx, Oct 02 2019]
Last message to Creation
https://en.wikipedi...ger_of_God_(Carina)
Big finger. I mean light-years big. [Frankx, Oct 02 2019]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Destination URL.
E.g., https://www.coffee.com/
Description (displayed with the short name and URL.)
|
| |
// the creator is asked a few questions to categorise the text.// |
|
| |
... to which the reply comes, "WE APOLOGIZE FOR THE INCONVENIENCE" ? |
|
| |
This is acceptable as long as they aren't Pink or Orange questions ..
on the whole we prefer Green questions. |
|
| |
//pink or orange//...//green// |
|
| |
Sorry, I don’t understand. Could you explain
please? |
|
| |
V&V - Verification and Validation. Core principles
for delivering systems well. “Did I explain what it
had to do properly” and “Does it do it” |
|
| |
Something that fell by the wayside when they spec'd the FCS for the 737MAX ... <Collective sniggering/> |
|
| |
// Could you explain please? // |
|
| |
We've experimented with using SBVR, a style-guide for writing requirements that is
well suited to machine-reading and information extraction. It's a kind of
bootstrapping vocabulary where you first define the terms you're going to use, in
english, and then, using more english, lay out how they might legally interact with
one another, and what kinds of relationships are acceptable. |
|
| |
Then, you can run a program to read all the text and generate a glossary, from this
you can retrospectively apply markup to label/link everything together. We're
planning to, once a bit more time presents itself, turn it into an entity graph.
From that graph we ought to be able to extract the main components, demonstrate the
flows, identify dead-ends and so on. |
|
| |
Once many of the definitions are setup, you plug these into an editor, and turn on
live colouring - like in a code editor - this further guides the business into
writing their specifications in parsable code - but only once a large enough corpus
exists to make that feasible. |
|
| |
We're nowhere near reaching critical mass, but it feels like it might be a neat way
of solving the documentation problem. |
|
| |
Neat. It’s only a question of database size and
mass until they start writing their own stories. |
|
| |
[zen_tom] - wow, that sounds really interesting.
Looked up SBVR and the idea is a good one -
defining terms rigorously has got to be a good
start, and extracting into parseable code sounds
genius. |
|
| |
I know there are model-based requirements
frameworks and requirement definition languages,
but so far the problem I have faced is getting
people (engineers and stakeholders) to use
anything other than Word to document
requirements. |
|
| |
Have you tried threats, backed up by actual violence ? We recommend it; cheap, and highly effective. |
|
| |
//threats//..//violence// |
|
| |
Yes, I’ve even tried actual face-to-face meetings
with chocolate biscuits. Which are remarkably
effective, but... |
|
| |
This is like a Pattern Language thing [link]. Lots of
people are comfortable with writing words that
describe what they want of a system. They’re used
to Word and Excel as tools to write those things.
But there are details that could be captured and
documented well, in a structured way, with some
small improvements. Forcing people to use a
formal system is counterproductive- either they
just don’t do it, or they farm the task out to the
least-experienced expendable body, who doesn’t
understand the details. |
|
| |
//apologise for the inconvenience// |
|
| |
GO STCK YOUR HEAD IN A PIG |
|
| |
... was the Sirius Cybernetics Corporation. |
|
| |
This [link] is the Creator’s last message |
|
| |