Our company has a documented process which requires the gathering of user need and then expanding upon them to create requirements. In addition potential hazards need to be reviewed and requirements to mitigate them must also be included in the design,.
We normall break the total requirements into classes (like basic functions, required functions, nice to have additions, etc) and implement a class per iteration (thru all stages) so that a product can be delivered early that the customer can evaluate and give feedback before final product is delivered.
In agile requirements can change at any time and in fact they are expected to. The idea behind the iteration is to plan what requirements are executed in that iteration and at the end of each iteration the project is reviewed, new reuqirements logged, and then the next set of requirements implemented. (Speaking in broad terms)
thank you so much. I'll listen to the archive since I missed the first few slides. For some reason Chrome didn't work I had to switch to firefox. I know a lot of people had problems also. See you tomorrow
no real question; my company is a service company, so customer requirements are the results of the service. try to get what technicians want. i am primary hardware designer, so i have to input how to get the hardware to work right. so, overall, software requirements are slow in coming, because technicians generally don't care until the tool gets into the field.
I don't go into too much detail on Agile specifically. I just mentioned it to help introduce the design cycle concept and that there are different ways to go about the design cycle. I'll focus more on the commonalities
I put both functional and non-functional requirements in the same document but I list them under different headings. So I might have an I2C requirement with functional and non-functional requirements so under I2C I list the background need then break it up into requirements.
bobybacs, there are trade-offs in different design cycles. What you'll find is that many of them have the same stages such as Requirements, Design, Consturction, etc but the methods they use within them vary from extremely strict to flexible.
Waterfall is generally not recommended because you have to be perfect upfront and there isn't a lot of room for error or changing requirements. I personaly like agile because it allows requirements to change and for me has been a pretty flexible process.
A funcational requirement describes the behavior of the system. It is a capability of the system. Non-functional requirements try to constrain the solution and are usually performance, safety, reliability related.
Do you have a recommended practice for software requirements? One practice we have been driving towards is to state requirements from the perspective of the output. The (named) Output shall (do something like turn on/off; increase/decrease) in response to (named) Input changing (state)(amplitude)(0ther).
We will cover test plan and test cases in more detail later this week. But as a preview the test plan will develop the process and resources that are used for testing where the test cases are simply do this, expect that and record what you saw.
We have had to lift the process up a level by adding User Needs and use cases. From this information that is used to create requirements. These requirements are then merges with IEC standards requirements.
Best way to get requirements we have found to to build a proof of concept that implements our best guess of the desired product. people have a lot easier time telling us what they DONT want than what they do want.
Again, we're currently working on making more formal design docs for our own sanity and to define project milestones. Currently spend a lot of time on conference calls and creating block diagrams and writing emails to nail down specs.
Hi all -Audio is live! If you don't see the audio bar at the top of the screen, please refresh your browser. It may take a couple tries. When you see the audio bar, hit the play button. If you experience audio interruptions and are using IE, try using FF or Chrome as your browser. Many people experience issues with IE. Also, make sure your flash player is updated with the current version. Some companies block live audio streams, so if that is the case for your company, the class will be archived on this page immediately following the class and you can listen then. People don't experience any issues with the audio for the archived version.
@kaddeam, The class begins exactly at the top of the hour (about 44 minutes from my posting here). The audio bar will appear below the Class title. If it does not appear within a few seconds after the top of the hour (by atomic clock accuracy), refresh your browser. Click on the audio bar. Don't forget to download the PowerPoint slide deck seen below the Special Educational Materials. Also, you might have problems with Internet Explorer. Use Chrome or Firefox.
The streaming audio player will appear on this web page when the show starts at 2 PM Eastern time today. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser. If that doesn't work, try using Firefox or Google Chrome as your browser. Some users experience audio interruptions with IE. If that doesn't work, the class will be archived immediately following our live taping.
The Smart Emergency Response System capitalizes on the latest advancements in cyber-physical systems to connect autonomous aircraft and ground vehicles, rescue dogs, robots, and a high-performance computing mission control center into a realistic vision.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.