Learning to work with user stories


Learning to work with user stories

Learning to work with user stories
— 사이트 계속 읽기: niksilver.com/2019/03/26/user-stories/

use case diagram or user story is considered in the business level, and if I map to development process, it is very close to ConOps or SOTIF level.

In some cases, we can try to use user story to sub-system’s development process, then it would be hard to make fit. Anyway learning various approach helps me to be more flexible, and have more agility. (I can use ‘agile’ but I didn’t use it because ‘agile’ become very popular, and many people use it without any knowledge)

Scope definition is very important to specify documents


ISO 26262 requires many kinds of documents. In my experience, engineers do not consider the scope. Thus it is apt to duplicate contents in many documents.

Assuming that such duplication is not allowed, and we have to think about what contents should be contained in specific document. These documents should be co-related each other, structures for documents are also necessary.

Topic that I pointed out is not engineer’s interest. It is prepared by functional safety manager or functional safety process organization group. If these consideration are not  carefully applied, it will obviously have trouble with traceability, consistency and completeness attributes.

For example, can you distinguish between Software integration testing and Software testing? Can you trace from SW architecture to SW integration testing? and Can you trace from SW requirement to SW testing? What are difference between System requirements and SW requirements?

If they are not clear,  systematic faults can be latent. As I mentioned in the past posting, engineers are not interested in this topic in general. Functional Safety Manager should care this kinds of fault by functional safety training or by safety plan.

Does usage of modeling tool achieve requirement for Semi-formal notation?


Of course not. I’ve experienced that they use Simulink tool as a drawing tool. They really spend too much for drawing tool. They should choose visio. It is great for drawing. Their Simulink modeling was not met for syntax and semantics.

I’d like to ask. Do you really think that usage of such an expensive tool can achieve semi-formal notation requirement?

Specifying semi-formal notation means that the design explains itself and it is able to  implement. But what if there are syntax errors? Then, it does not meet for semi-formal notations requirement. The design cannot explain itself. There maybe several ways of interpretations. But it is not the intention of semi formal notation requirement.

If you try to use UML diagram, then please consider syntax and semantics. It is really important. Do not use it just for “drawing tool”. You are not an artist. and it cannot be an art. Please do engineering, not art.