Live data from Hacker News

Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

pdfs.semanticscholar.org

11–20 of 40 posts

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#11
post #9

Earlier quoted context omitted.

I think Product Lifecycle Management (PLM) is the buzzword your looking for.

PLM I'm familiar with, though none of the ones I've seen seem to focus in any particular was on the requirements/specification end of the equation...

Ah okay. So PLM systems would be used to store and manage the requirements, the requirement documents are going to be, at least in my corner of the world... Word and/or Excel templates.

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#12

Earlier quoted context omitted.

It looks like you are looking for the V-Model development process used in the industry (e.g. automotive). A typical requirement in this model is handled like this: 1. the high level specification define what is the change about (e.g. implement a hillholder function). 2. architecture phase: you identify which part/module of the system are impacted by the high level requirement. You define what each part will do and yo…

Oh—also—do you know what software out there is already used for managing this complexity? Thanks again!

I've used DOORS. It was adequate, though not a pleasure to use. (It might have been a pleasure if the alternative was doing it manually...)

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#13

Earlier quoted context omitted.

Oh—also—do you know what software out there is already used for managing this complexity? Thanks again!

I've used DOORS. It was adequate, though not a pleasure to use. (It might have been a pleasure if the alternative was doing it manually...)

Having done it manually, DOORS is a dream.

I haven’t used a recent incarnation of it though. It’s UI circa 2008-2010 was entirely mediocre but sufficient for the task.

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#14

Can anyone recommend any links/articles/books about the relationships between specification, implementation, testing, provability, TDD, BDD, etc.? I have been working on designing some software for improving the specifications process, and quickly realized that it's a very interconnected concept: the specification can be treated very formally, leading to things like BDD (behavior-driven development), but also to thin…

Design to specification can be handled using systems like DOORS or other requirements management software. There’s an interchange format (XML) that many of these support called ReqIF. If you look that up you’ll find an Eclipse based tool (RMF) that is free and let’s you see how linking between requirements and such can be done.

I’ve not seen tracing attempted down to the code level though we did do tracing to the test procedures.

There’s a plug-in for Event-B in Eclipse that can, in theory, play well with RMF (connect requirements and specs to elements of the formal model). I’ve not spent much time with it but it did seem to do the job.

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#15
post #11

Earlier quoted context omitted.

PLM I'm familiar with, though none of the ones I've seen seem to focus in any particular was on the requirements/specification end of the equation...

Ah okay. So PLM systems would be used to store and manage the requirements, the requirement documents are going to be, at least in my corner of the world... Word and/or Excel templates.

Which is only narrow subset of what PLM system does. PLM is generally about tracking what data artifacts (drawings, manufacturer datasheets and so, formal specifications are somewhat secondary to that) are relevant for given assembly and how such subassemblies fit together on high level.

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#16

Can anyone recommend any links/articles/books about the relationships between specification, implementation, testing, provability, TDD, BDD, etc.? I have been working on designing some software for improving the specifications process, and quickly realized that it's a very interconnected concept: the specification can be treated very formally, leading to things like BDD (behavior-driven development), but also to thin…

The thing the specs have in common with your code is they represent entities involved in the systems operation internally or externally to as abstract or concrete detail as you require. They also typically represent the structure and/or order of your system's activities. The abstractions that hide messy details of the machine can let you more easily analyze properties of your system with your eyes, spec/model-checkers, or proof. Some can generate tests from specs. Then, the code's modules should map closely to those abstract actions so you mainky just have to analyze code for isdues that just show up in those parts.

The easiest method to start with is Design by Contract plus property-based and fuzz testing. By itself, it lets you specify key properties that are highlighted during a test or runtime failure. Combined with SPARK Ada, you can prove the code is correct against those specs.

https://www.eiffel.com/values/design-by-contract/introductio...

http://www.anthonyhall.org/c_by_c_secure_system.pdf

https://en.m.wikipedia.org/wiki/SPARK_(programming_language)

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#17
post #9

Earlier quoted context omitted.

I think Product Lifecycle Management (PLM) is the buzzword your looking for.

PLM I'm familiar with, though none of the ones I've seen seem to focus in any particular was on the requirements/specification end of the equation...

JAMA is a more recent one that's fairly modern feeling. I tried to get my company to get it but they didn't bit. (pricey)

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#19
post #11

Earlier quoted context omitted.

PLM I'm familiar with, though none of the ones I've seen seem to focus in any particular was on the requirements/specification end of the equation...

Ah okay. So PLM systems would be used to store and manage the requirements, the requirement documents are going to be, at least in my corner of the world... Word and/or Excel templates.

Right, and this is actually exactly the area that I am interesting in improving: providing a canonical, systematic way to store and represent the actual requirements & specifications, and provide ways to feed into other software such as PLM or project management, etc.

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#20
post #15
post #11

Earlier quoted context omitted.

Ah okay. So PLM systems would be used to store and manage the requirements, the requirement documents are going to be, at least in my corner of the world... Word and/or Excel templates.

Which is only narrow subset of what PLM system does. PLM is generally about tracking what data artifacts (drawings, manufacturer datasheets and so, formal specifications are somewhat secondary to that) are relevant for given assembly and how such subassemblies fit together on high level.

Yes, that's much more of what I am aware of in the context of PLM. As I wrote in a sibling comment, I'm interested in improving the storage and representation of the requirements/spec itself...
Post reply on HN