Requirements Featues and Different Types of Issues
Content
Features, Use Cases, Requirements, Oh My! Functional Requirements Functional requirements express what the system does. More specifically, functional functional requirements describe what the inputs are, what the outputs are, and how it is that specific inputs are converted to specific outputs at various times. Most software applications conceived conce ived to do useful work are rich with functional requirements. When specifying these requirements, it’s important to strike a balance between being too vague !When you push the "n button, the system turns on#$ and being too specific about abou t the functionality. %t’s important to give the designers and implementers as wide a range of design and implementation choices as possible. %f we’re too specific, we may over&constrain the team and if we’re too wishy&washy, the the team won’t know what the system is supposed to achieve. Nonfunctional Requirements %n addition to functional requirements such as inputs translating to outputs, most systems s ystems also require the definition of a set of nonfunctional requirements that focus on specifying additional system !attributes#, such as performance requirements, throughput, usability, reliability reliability,, and supportability.. 'hese requirements are (ust as important as the input&output oriented functional supportability requirements. 'ypically, 'ypically, nonfunctional requirements are stated declaratively using exp expressions ressions
such as !'he system should have a mean time between failure of ),** ),*** * hours#, !'he system shall have a mean time to repair of *.+ hours#, and !'he martbot shall be able to store and retrieve a maximum of -** weld paths# Design Constraints s opposed to defining the behaviors behav iors of the system, this third class of requirements typically imposes limitations on the design of the system or process we use to build the system. We’ll We’ll define a design constraint as restrictions upon the design of o f a system, or the process by which a system is developed, that do not affect the external behavior of the system, but must be fulfilled to meet technical, business or contractual obligations. typical design constraint might be expressed as !/rogram the welder control unit in 0ava#. %n general, we treat an any y reasonable design constraints (ust like any other requirements although testing compliance to such constraints may require different techniques. 0ust like functional and nonfunctional requirements,
these constraints can play an integral role in designing and testing the system. Hierarchical Requirements Many pro(ects benefit from expressing these requirements in a hierarchical or parent&child structure. parent&child requirement is an amplification of the specificity expressed in a parent requirement. /arent&child requirements allow you a flexible way to enhance and augment your specification, while at the same time organi1ing the depth of detail presented. 2y looking only at the parents, it’s straightforward to present the top&level specification in a way that is easily understandable by the users. t the same time, the detailed !child# specification can be quickly inspected by the implementers to make sure that they understand all of the implementation details. 3ote that hierarchical requirements consist up of the standard three types of requirements4 requirements4 functional, non&functional, and design constraints. %t’s only the elaboration relationship between these requirements that is defined here.
JIR ystem Feature oftware Feature is oftware rchitectural 5esign artifact. artifact. "ne oftware 6equirement can c an be fulfilled by development of one or more oftware Features. "ne oftware Feature can fulfill one or more oftware 6equirements. %t should be described by b y the oftware rchitect. Requirement oftware 6equirement is oftware 6equirements 6equ irements nalysis nalysis artifact. %t can be functionality, feature, performance requirement, usability requirement, design requirement, product characteristic, etc. %t should be described by the 6equirements72usiness nalyst. tory story or user story is a software system requirement that is expressed in a few short sentences, ideally using non&technical language. %n 0%6 gile, a story is represented as an issue, and individual tasks within the story are represented as sub&tasks. "as# 'asks 'asks are work records or work orders that are not linked to any particular software item. 'asks 'asks
can be installation task, integration task, configuration task, management task, planning task, reporting task, documentation task, design task, meeting, etc Unit oftware 5esign 8nit is oftware 5etailed 5esign artifact. %t describes the smallest testable chunk of code. 8nit testing is performed by b y the oftware 5evelopment team. Mo$ification Request 6equest for 9orrection or :nhancement in the software, raised during its operation in a production system. 'he 9orrection in the software can be 9orrective, 9orrective, to solve a problem, or /reventive. 'he :nhancement in the software can be daptive, upon a client requirement or /erfective, for improvement in the software. M6s are reported by the oftware Maintenance 5epartment. Change Request :nhancement to an existing software or its part. 6eported by the oftware ;uality ssurance 5epartment. 'he 96s can be adaptive, preventive or perfective.
nomaly Re%ort 6 is defect in the software or failure of the software or some of its parts. nomalies are reported by the oftware ;uality ssurance 5epartment. &ug 2ug is a problem which impairs or prevents the functions of the product.
Iterations 's( %rints ll sprints are iterations but not all iterations are sprints. %teration is a common term in iterative and incremental development %%5$. crum is one speciali1ed flavor of %%5 so it makes sense to speciali1e the terminology as well. %t also helps brand the methodology different from other %%5 methodologies <$
s to the sprint length< anything goes as long as the sprint is time boxed i.e. it is finished on the planned date and not =when it>s ready=. "r alternatively, in rare occasions, the sprint is terminated prematurely to start a new sprint in case some essential boundary bound ary conditions are changed.$ %t does help to have the sprints of similar durations. 'here>s less to remember about the sprint schedule and your planning gets more accurate. % like to keep mine at ) calendar weeks, which will resolve into ?@-* business days outside holiday seasons. )elocity Definition )elocity Def inition %n crum, velocity is how much product backlog effort a team can handle in one sprint. 'his can be estimated by viewing previous sprints, assuming the team composition composition and sprint duration are kept constant. %t can also be established on a sprint&by&sprint basis, using commitment&based
planning. "nce established, velocitycomputations can be used tobeplan pro(ects and forecast release and product completion dates. Aow can velocity meaningful when backlog item estimates are intentionally roughB 'he law of large numbers tends to average a verage out the roughness of the estimates. Descri%tion 'he value of velocity is a percentage with a default value of -**C. %f your team>s velocity is generally slow, respectively over&estimate over&estimate themselves, please ad(ust the parameter below. For example< enter >D+> als velocity, if your team finished an amount of D+C of the issues they have estimated within a time period. 2ased on this velocity parameter, planned start dates will be calculated as planned end date minus original estimation duration of estimated effort taking weekends into account$ multiplied by the velocity factor to stretch the timeline. 'he velocity
factor will be calculated internally as -**7velocity and is -.EEE in this example< E days da ys effort needs working days to be finished.
'" 2: ; /roactive, Geen to details, 9onversant7certified 9onversant7certified with international testing and certification bodies, ;M knowledge in your area of speciali1ation speciali1ation,, solving technical quality issues amicably a micably,, team work, understanding process standard operating procedures, making concrete and firm decisions in view of quality, honest and firm. Hoyal to your work, knowledge, ability to take decision, and keen interest to update all ; skills First you should practice the ; by yourself in an established system, be knowledgeable, ability to talk decision and make a good brain storming activity in each problem that face you and finally it really like a talent that appear in the ssiduous person % believe, that aside from the numerous training courses available, attitude is one of the key factors in being a successful ; /rofessional. /rofessional. %>ve experienced =; /rofessionals= /rofessionals= that have a alphabet of certs behind their names, that in my opinion are not really professional in their approach. 8nderstand that there are gray areas in ;, not everything is totally black and white. 2e the person that is willing to teach, mentor, and help rather than the dreaded box checker. %>ve said it before when this question has appeared in group discussions, but a thick skin, sense of humor and the patience of an angel spring to mind instantly. /atiently /atiently explain =why= you have to do things a particular way rather (ust telling people to do it. %f people understand the rationale behind the processes and feel a part of it, it, especially in a complex ssupply upply chain, they are les lesss likely to cause prob problems lems along the way. %t>s also important to make sure people understand that ;uality is something that they all need to understand and contribute to, not something the ;M does to or for them. Iour Iour role is to create and steer the systems that contribute to the success of the company as a whole. 5on>t (ust think about it as keeping the pretty picture on the bottom of the letterhead or the certificate on the wall. 2elieve that applying the spirit of a standard is beneficial to the business, the customers and therefore ultimately the staff who stay in a (ob. :thics, communication skills Jwritten and "ralK, product knowledge, people skills, 'echnical 'echnical skills, :ffective decision making, presentation presentation skills, 9omputer skills, and a stiff drink at the end of each day. Commitment*$ri'en iteration %lanning & 5iscuss the highest priority item on the product backlog< L5ecompose it into tasks
L:stimate each task LWhole team estimates each task Lsk ourselves, !9an we commit to thisB# L%f yes, see if we can add another backlog item L%f not, remove this item but see if we can add another smaller one.
+I- "I. ND "RIC/
•
5o retrospectives
•
et competent team members
•
9ontinuous integration from day one.
•
8se Flowdock or similar tool for digital communication not kype
•
n endless backlog is waste
•
'here is no value in tracking all bugs. %t is ok to forget a bug which was not important enough to fix right away.
•
/ull request are a good way to manage peer reviews
•
We like peer reviews
•
5efinition of done. Aave one.
•
%f you are faced with a distributed team rotate people so that everybody personally knows and regularly works with all team members7/"7M face&to&face.
•
horten sprint length if the scope doesn’t seem to be stable. •
•
%f the sprints are unstable, but you have a very stable flow you can consider switching to Ganban. 'o reduce a story in si1e ask what is the value of the story is and how can we deliver ?*C of that value in a shippable way wa y of course$. o
•
•
'o reduce more, get inspiration from e.g. a printed plitting tory Flowchart. Flowchart.
5on’t release on Friday. 9reate a table which shows who is present and who isn’t for the coming week
•
•
•
•
•
•
'he daily standup shall not exceed -+ minutes, unless you decide its ok of course <$ 5on’t decide too often, and only for learning purposes so that future 5ailies are less than -+ minutes$ 'o keep a daily short, don>t discuss in depth, save that for after the daily. n alternative for daily standup what did7will % do$ is what did % learn, what do % need to learn today and how you can help me second alternative is -$ What do others need to know about the things % did yesterday, )$ What can % get from, or how can % collaborate with others to get things don donee effectively today, E$ What is blocking my effective workB 'he crum Master should have time to observe eg not busy with -**s of tasks$ good /" is very important. 'ake 'ake some time in the beginning of the pro(ect to identify the constraints the /" has in terms of availability to the team, authority to make scope and budget decisions, domain knowledge, access to stakeholders.
•
Weekly We ekly smiles sharing your mood$ within the pro(ect team are good
•
"n site is the best place to do d o a pro(ect
•
%ndex cards are great for planning sessions, any digital tool sucks.
•
gile is a mindset not a rigid method.
•
•
•
Iou can break any rule if and only if you understand Iou u nderstand why the rule was there in the first place. 'he team should own the tools it uses. ny tool that forces a process on the team limits the capability of the team to optimi1e creating awesomeness
•
Minimi1e the time and effort needed to make a release
•
pecification by example N automate them
•
/air&work
•
'reat HH specs as speculation
•
•
:stimations are not commitments, they are estimations i.e. (ust guesses, predictions$ face&to&face constructive feedback is good + minutes between all team members twice a year$
0 "i%s for +oo$ crum 1y crum 1y Martin Harris O O If If you are doing these 6 tips, then you are are doing very well and are likely to get better overti overtime me O •
produ ct owner should be part of o'e your %ro$uct o2ner. 'he group agreed that the product the team. %nclude them in the meetings and get them involved. %ts possibly the most important thing you can do for success in scrum. fully integrated product owner will spot early on if the stories do not match their expectations. 'hey negotiate the definition of done for a story. 'hey are on hand to answer questions during the iteration removing waste and improving understanding of the stories. 'he product owner decides if the team has finished stories at the demo. Working Working closely with the product owner can avoid going adrift and missing your goals, saves a lot of stress when things hit a rough patch as the they y get to see the problems first hand. We agreed that this point can not be understated, if you do nothing else do this.
•
Run Retros%ecti'es. %ts very important to take actions away from a retrospective. 2e realistic though, your never going to to solve them all, so ask the team to priorities priorities them. %f your doing the retrospective right your product owner will be there to help with prioritisation. %f you find something very big lands at the top, split it down into stories. stories. "therwise pick one or two that the team feel strongly about and turn them into stories. Make sure these stories are included in the next game planning sessions and make it into the iterations. %f you have ad(ustments to to the process you can implem implement ent these straight away, but experiment with it, and try to measure the impact of changes, change s, you might not get the process right first first time. 9ommit to doing them and then then deliver.
•
technique s# your team to .air Co$e 3 Co$e 3My defnition o Pair Programming: A technique to increase development throughput by maximizing review coverage, reduction in faults leading to increased software quality and less eort in downstream processes such as manual testing and product maintenance. maintenance.44. 'he P/ technique of two programmers working on the same task. %t was agreed that there there are different kinds of pair coding and that they they all have a place, but the one we are talking about here is where two equal programmers work together to improve quality and throughput. throughput. 5on’t be dogmatic, let let the team decide how much work should be pair coded.
•
etu% elf Directe$ teams. elf directed teams have been proven to be more efficient. We discussed the role of a scrum master in a self dir directed ected team. %ts very important that the scrum master does not tell the team how ho w to work, or how to go about completing the tasks. 'he scrum master master does not plan or allocate tasks. tasks. 'he empowered team needs to work out what the tasks are and find out how to finish the stories. stories. 'he scrum master
should spend his efforts removing blocks for the the team, checking quality. %ts important for
the team and scrum master to spot if someone is not completing their work for whatever reason, but a strong team will sort out those kinds of issues issues if truly self directed. We also decided that to be empowered you need to make make the team multi discipli discipline. ne. %nclude testers, user interface designers etc to remove hand off waste and increase team knowledge. With With role diversity diversity comes better decision making. •
Deli'er 2hat you commit to . nother gem, it sounds obvious but is so often ignored. 5elivering builds trust in the team and the process. 9lassic ways to miss delivery include< Failing to produce a strong strong definition of done. 'he definition should include include the programming, integration, testing and setup tasks. %n fact everything required to get that task ready for delivery. nother way to miss delivers iiss to fail to demonstrate at the end of the iteration. Iou may think your done, but when the product owner sees the work for the first time time they may request refinement. %f you have kept your product owner close then the demo is likely to be painless. 3o power&point slides slides please, only real working software in the demoQ o commit and then deliver what you commit to.
•
Co*locate your team. 'he group defined co&location co&location quite tightly. tightly. 9o&location is not putting everyone in the same office. %ts putting the team members next to each other in the same space. %ntra team communication does not happen with the team scattered
around an office. Iou should be able to turn around and (oin (oin the stand up meeting. 'his closeness, speeds up the myriad of tiny important messages that pass around the team. ome of which is non verbal. fter this rich rich discussion we gave up on the -+ tips idea. %f your doing these, then your your doing very well indeed, and are likely to get better over time. o another excellent meeting, a few more beers and % headed home enlightenend, well fed and slighlty merry. merry. Why not come along to the next one, we could use your input. http<771enexmachina.wordpress.com7)*-)7*E7E*7-*&tips&for&adopting&scrum&to&save&your& pro(ect7
